Since a few here are using gilab-ci I figure this might be either interesting for people to find out or someone might already know.
I’ve played with gitlab-ci yesterday and also right now.
The end result looks somewhat like this
Now that looks GREAT, but what I wanna achieve is two identical pipelines for building a docker image for JRiver Media Center, both the stable and the latest version. But have the stable and latest build be able to fail independetly. This is good if the latest build stops working or most likely whenever version 26 comes out there won’t be a stable version right away. Right now if latest where to fail the build the test stage would not even begin, even though stable might have succeeded.
The current gitlab-ci.yml you can find here. If you are interested.
image: docker:latest services: - docker:dind stages: - build - test - release before_script: - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY # JRiver Media Center 25 (stable) build-master-stable: stage: build script: - ./scripts/build.sh 25 stable only: - master test-master-stable: stage: test script: - ./scripts/test.sh jrivermc:stable dependencies: - build-master-stable only: - master release-master-stable: stage: release script: - ./scripts/release.sh jrivermc:stable stable dependencies: - test-master-stable only: - master # JRiver Media Center 25 (latest) build-master-latest: stage: build script: - ./scripts/build.sh 25 latest only: - master test-master-latest: stage: test script: - ./scripts/test.sh jrivermc:latest dependencies: - build-master-latest only: - master release-master-latest: stage: release script: - ./scripts/release.sh jrivermc:latest latest dependencies: - test-master-latest only: - master
I already tried to add more stages. Like build-stable, build-latest, test-stable… You get the idea. That ends up being a single long line. Accomplishes nothing, other than the build jobs can’t even run in parallel anymore.
I’m not sure yet from what I found if that’s possible at all quite the way I would want it. I would know workarounds by making pipelines not-fail and instead write something somewhere that indicates it failed until I get to the release stage, then it can fail. But it’s awkward, tedious and not very pretty.