6

I want to separate the maven stages to build, test and deploy.

Question: am I over complicating things here? Should I maybe just use a mvn clean package stage, because compile and test are executed implicit by maven during package phase?

.gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script: mvn clean compile

test:
  stage: test
  script: mvn clean test

deploy:
  stage: deploy
  script: mvn clean package -Dmaven.test.skip=true
  #...continue with docker deployment...
snieguu
  • 2,073
  • 2
  • 20
  • 39
membersound
  • 81,582
  • 193
  • 585
  • 1,120
  • Yes in the end you are...cause as you already mentioned yourself things like `compile` and `test` are running by `package` ...furthermore if you do `mvn clean deploy` also compile,test,package is done...?The question is why you like to separate those things? – khmarbaise Jan 20 '20 at 12:21
  • 1
    Because gitlab-ci has those 3 default stages, and when the build and project gets bigger, one could directly see if the failure was within the compile, test or package phase without having to look at the logs. – membersound Jan 20 '20 at 12:37
  • If some has a issue you need to read the logs ...and making things more complicated than needed will not help... – khmarbaise Jan 20 '20 at 12:39

2 Answers2

0

There are two questions in the post.

How to separate test and build stage with maven in gitlab-ci?

This is possible and can be done like this, as mentioned in GitLab maven example:

image: maven:latest

variables:
  MAVEN_OPTS: >-
    -Dhttps.protocols=TLSv1.2
    -Dmaven.repo.local=.m2/repository
    -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN
    -Dorg.slf4j.simpleLogger.showDateTime=true
    -Djava.awt.headless=true

  MAVEN_CLI_OPTS: >-
    -s .gitlab-ci_settings.xml
    --batch-mode
    --errors
    --fail-at-end
    --show-version
    -DinstallAtEnd=true
    -DdeployAtEnd=true
    -Dstyle.color=always

cache:
  paths:
    - .m2/repository/
    - target/

mvn-compile-job:
  stage: mvn-compile
  script:
    - mvn $MAVEN_CLI_OPTS compile

mvn-test-job:
  stage: mvn-test
  script:
    - mvn $MAVEN_CLI_OPTS test

mvn-deploy-job:
  stage: mvn-deploy
  script:
    - mvn $MAVEN_CLI_OPTS deploy
  only:
    - master

Question: am I over complicating things here?

This really depends on what has to be done and what would you like to achieve. For example, this is great solution if you would like to run different phases on different branches (in the example above we run mvn deploy only on master branch).

However, on a single branch running separate stages comparing to just mvn deploy from the beginning takes more time on docker runners, since every GitLab job run requires image pulling. This is just something to consider when configuring CI/CD for maven repositories.

ololoid
  • 63
  • 5
0

If anyone stumbles across this, here's a nice breakdown about how artifacts work I figured when I was trying to do something simillar.

stages:
  - build
  - test

build hello:
  stage: build
  image: alpine:latest
  script:
    - echo "Hello $PWD" > hello.txt
  artifacts:
    paths:
      - ./hello.txt
    expire_in: 1 hour

build goodbye:
  stage: build
  image: alpine:latest
  script:
    - echo "Goodbye $PWD" > Goodbye.txt
  artifacts:
    paths:
      - ./Goodbye.txt
    expire_in: 1 hour

test goodbye:
  stage: test
  image: alpine:latest
  script:
    - test "`cat Goodbye.txt`" == "Goodbye $PWD"
  dependencies:
    - build goodbye


test hello:
  stage: test
  image: alpine:latest
  script:
    - test "`cat hello.txt`" == "Hello $PWD"
  dependencies:
    - build hello

test both:
  stage: test
  image: alpine:latest
  script:
    - test "`cat hello.txt`" == "Hello $PWD"
    - test "`cat Goodbye.txt`" == "Goodbye $PWD"

test fail_hello:
  stage: test
  image: alpine:latest
  script:
    - test "`cat Goodbye.txt`" == "Goodbye $PWD"
  dependencies:
    - build hello

test fail_goodbye:
  stage: test
  image: alpine:latest
  script:
    - test "`cat hello.txt`" == "Hello $PWD"
  dependencies:
    - build goodbye

The test fail_ jobs will fail.

Other jobs will succeed.

Basically you can specify an artifact path to keep for a certain ammount of time, which you can use later. (even download it from the web GUI)

The way it works is you specify artifacts: arrays in the jobs where you create them.

Then in the jobs where you want to use them, if you do not specify the dependencies: array, you'll have all the previously created artifacts available.

If you want to have access only to artifacts from certain jobs, you can specify dependencies: array, which will hold names to those jobs.