Project Maven Muti-module, how to control which artifacts Gitlab-CI should deploy?

Asked

Viewed 153 times

0

I have a multi-module Maven project in Gitlab. The structure is about the following:

/pom.xml                                          --> reator
/cooker/
/cooker/pom.xml                                   --> biblioteca principal
/security-clean/
/secutiry-clean/pom.xml                           --> dependência opcional de cooker
/samples/
/samples/pom.xml                                  --> reator dos projetos de exemplo
/samples/samples-cooker-cli-no-security/
/samples/samples-cooker-cli-no-security/pom.xml   --> exemplo sem o security
/samples/samples-cooker-cli-security/
/samples/samples-cooker-cli-security/pom.xml      --> exemplo sem o security
/samples/samples-cooker-spring-boot/
/samples/samples-cooker-spring-boot/pom.xml       --> exemplo rodando com o spring-boot

The pom.xml of the main reactor consists only of the insertion of modules (group, artifact, version were artificially placed data):

<module>cooker</module>
<module>security-clean</module>
<module>samples</module>

The reactor of samples mentions the examples, but his focus is to help do the automated compilation/testing I need, not the focus of the issue.

In the .gitlab-ci.yml, I have 2 Janobs at different times:

build:
  stage: build-test
  script:
    - mvn $MAVEN_CLI_OPTS clean test -am -pl :samples-cooker-cli-no-security,:samples-cooker-cli-security

archive:
  stage: archive
  script:
    - mvn $MAVEN_CLI_OPTS -DskipTests clean deploy -am -pl :cooker,:security-clean
  artifacts:
    paths:
      - "target/*.jar"
    expire_in: 1 week
    when: on_success
  dependencies:
    - build
  only:
    - tags

So far, all quiet. However, the expectation of changes in secutiry-clean is zero: is an artifact of the type pom which consists of the dependency of a legacy project, but with the removal of all transitive dependency (this legacy project was very badly modeled, it is necessary to have a "clean dependency").

However, as I must do in Gitlab-CI to avoid resending the security-clean? And the possible need for some unscheduled maintenance on security-clean, how to indicate that this artifact should be sent?

  • I would like to know how I can improve my question, since it has not shown itself worthy of being closed. I would be very grateful for the feedback

1 answer

2


Just put the plugin exists.

When I started my search for this, my first idea would be to solve it through shell script itself. I would get the version through the help:evaluate, put it in a variable and find out if it already existed on the server.

How to do that? Well, here comes the complication... But, a priori, knowing that my artifact server is under a fixed name (let’s call it http://artifactory), could check if the artifact was there:

curl http://artifactory/libs-release/group/id/artifatic-id/M.m.i/
#    \________________/ \__________/ \______/ \__________/ \___/
#             |              |            |        |         |
#             |      nome do repositório  |  meu artifactId  |
#             |                           |                  |
#    autoridade do servidor            meu groupId     minha versão em questão

An unsuccessful return (no artifactory, at least), when there is no such version of the artifact, it occurs with a 404 code and the following output:

{
  "errors" : [ {
    "status" : 404,
    "message" : "{\"error\":\"children items not found on all virtual repos\"}"
  } ]
}

Already a successful, beyond the code 200, a page with the links to download the pom and the artifact generated:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head><title>Index of libs-release/group/id/artifatic-id/M.m.i</title>
</head>
<body>
<h1>Index of libs-release/group/id/artifatic-id/M.m.i</h1>
<pre>Name                     Last modified      Size</pre><hr/>
<pre><a href="../">../</a>
<a href="artifatic-id-M.m.i.jar">artifatic-id-M.m.i.jar</a>   10-Jul-2019 20:59  25.82 KB
<a href="artifatic-id-M.m.i.pom">artifatic-id-M.m.i.pom</a>   25-Jul-2019 17:28  5.97 KB
</pre>
<hr/><address style="font-size:small;">Artifactory/6.3.0 Server at artifactory Port 80</address></body></html>

But luckily I would have to worry about rescuing which repositories serve dependencies exist via help:evaluate. The fact of possibly containing inheritance of pom makes it difficult to try to solve this via grep or other simple agnostic textual analysis tools from Maven.

While searching for a way to list the repositories, I came across the plugin org.honton.chas:exists-maven-plugin. Its use is very simple: configures whether it should be used with the Goal local or remote and have it executed. In this case, I simulated the following in a toy design to avoid replacing my artifact (which is SNAPSHOT) in the local repository:

  • Plugin configuration:
<build>
    <pluginManagement>
        <plugins>
            <!-- outros plugins -->
            <plugin>
                <groupId>org.honton.chas</groupId>
                <artifactId>exists-maven-plugin</artifactId>
                <version>0.1.0</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>local</goal>
                            <!-- para repositórios remotos, mude o goal para
                            <goal>remote</goal>
                            -->
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </pluginManagement>
    <plugins>
        <!-- outros plugins -->
        <plugin>
                <groupId>org.honton.chas</groupId>
                <artifactId>exists-maven-plugin</artifactId>
                <version>0.1.0</version>
            </plugin>
    </plugins>
    <!-- outras opções de build -->
</build>

And I ran the following command:

Note that as I’m playing with an artifact SNAPSHOT, I needed to turn off the configuration exists.skipIfSnapshot with the option -Dexists.skipIfSnapshot=false

$ mvn -pl :artifact-id install -Dexists.skipIfSnapshot=false

When I run it clean, it follows the installation normally:

$ mvn -pl :artifact-id install -Dexists.skipIfSnapshot=false

....

[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ artifact-id ---
[INFO]
[INFO] --- exists-maven-plugin:0.1.0:local (default) @ artifact-id ---
[INFO] group.id:artifact-id:M.m.i-SNAPSHOT does not exist
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ artifact-id ---
[INFO] Installing ...

When I run again:

$ mvn -pl :artifact-id install -Dexists.skipIfSnapshot=false

....

[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ artifact-id ---
[INFO]
[INFO] --- exists-maven-plugin:0.1.0:local (default) @ artifact-id ---
[INFO] setting maven.install.skip=true
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ artifact-id ---
[INFO] Skipping artifact installation

This also applies to projects within a reactor, as the above example demonstrates.

It is important to note that, to use the exists-maven-plugin, it is necessary to run with the Maven version at least 3.5.0. Running in earlier versions has a result much strange. If you simply ask if the artifact exists (for example, calling the mojo org.honton.chas:exists) and just that, everything works fine. However, when putting to run together install, a great stacktrace is printed without major tips.

I see this if you use the maven-wrapper

Browser other questions tagged

You are not signed in. Login or sign up in order to post.