We're using Mainline mode so that we don't have to tag every merge into master. But we use a 'develop' branch (sourced from 'master') and 'feature' branches (sourced from 'develop').
However our 'feature' branches seem to calculate versions based on the 'master' branch and not the 'develop' branch. Is there an easy fix to make the 'feature' branches base their version off of the 'develop' branch so their version relfect that they are working toward the next Minor release?
We automatically deploy prereleases built from 'develop' to our dev & qa environment.
We automatically deploy stable versions built from 'master' to our staging environment (and then manually trigger them to deploy to production).
Does GitVersion support the following scenario:
merging develop into master generates a stable release without tagging (0.1.0)
merging feature branches into develop generate a prerelease of the next minor version we're working toward (0.2.0-alpha0002)
feature branches are branched off of develop and have the next minor version we're working toward (0.2.0-jira-123-0004)
we'd like this:
master (0.1.0)
develop (0.2.0-alpha0002)
feature (0.2.0-jira-1234-0004)
but are instead getting this:
master (0.1.0)
develop (0.2.0-alpha0002)
feature (0.1.1-jira-1234-0004)
mode: MainLine
branches: {}
ignore:
sha: []
I've been banging my head against this for a week. I've read the docs, even downloaded the source code.
I've tried several combinations of mode, is-mainline, source-branches, etc, but always wind up with version collisions.
mode: MainLine
branches:
develop:
is-mainline: true
is-source-branch-for: ['feature']
feature:
increment: Minor
source-branches: ['develop']
ignore:
sha: []
It seems like the only way to get GitVersion to predict the next stable version for both develop and feature branches is by using ContinuousDeployment mode and tagging commits on master.
This solved my problem:
mode: Mainline
branches:
feature:
regex: ^feature?[/-]
increment: Minor
hotfix:
tag: 'hotfix-{BranchName}'
ignore:
sha: []
merge-message-formats: {}
Related
How do I add a label to the GitLab pipelines when they run?
This would be extremely helpful when you run a few nightly (scheduled) pipelines for different configurations on the main branch. For example, we run a nightly main branch with several submodules, each set at a point in their development (a commit point SHA) and I want to label that 'MAIN'. We run a second pipeline that I want to label 'HEADs', which is a result of pulling all of the HEAD's of the submodule to see if changes will break the main trunk when they are merged in.
Currently it shows:
Last commit message.
Pipeline #
commit SHA
Branch name
'Scheduled'
That is helpful, but it is very difficult to tell them apart because only the pipeline # changes between the pipelines.
I have good news!!
Our friends at GitLab have been working on this feature. There is now a way to label your pipeline in release 15.5.1-ee.0!
It uses the workflow control with a new keyword name
workflow:
name: 'Pipeline for branch: $CI_COMMIT_BRANCH'
You can even use the workflow:rules pair to have different names for you pipeline:
variables:
PIPELINE_NAME: 'Default pipeline name'
workflow:
name: '$PIPELINE_NAME'
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
variables:
PIPELINE_NAME: 'MR pipeline: $CI_COMMIT_BRANCH'
- if: '$CI_MERGE_REQUEST_LABELS =~ /pipeline:run-in-ruby3/'
variables:
PIPELINE_NAME: 'Ruby 3 pipeline'
Find the docs here: https://docs.gitlab.com/ee/ci/yaml/#workflow
This feature is disabled by default in 15.5 because it is so new.
You can enable the feature flag, which is named pipeline_name.
See this link to enable: https://docs.gitlab.com/ee/administration/feature_flags.html
(You need to use the Rails Console to enable it. Pretty easy.)
Note: Remember that the workflow keyword affects the entire pipeline instance.
This seems to be officially supported with GitLab 15.7 (December 2022)
Add custom names to pipelines with workflow:name:
For some projects, the same pipeline can be configured to run differently for different variables or conditions, creating very distinct outcomes for successful pipelines.
It can be hard for you to determine which version of that pipeline ran since there is no indication about the inputs used for that particular run.
While labels like scheduled and API help, it is sometimes still difficult to identify specific pipelines.
Now you can set a pipeline name using the keyword workflow:name to better identify the pipeline with string, a CI/CD variable, or a combination of both.
See Documentation and Issue.
Note:
If the name is an empty string, the pipeline is not assigned a name.
A name consisting of only CI/CD variables could evaluate to an empty string if all the variables are also empty.
I have a multi-module build with one "leading" module and one additional one. I have set things up so that the additional module is only built when either it or the build files have changed:
build:sbt:module-main:
extends: .build-sbt
build:sbt:module-a:
extends: .build-sbt
only:
changes:
- module-a/**/*
- project/**/*
- "*.yml"
- "*.sbt
The behaviour I observe is that in a pipeline resulting from pushing a new branch, both modules are always built, regardless of the actual changes. Then when new commits are pushed to the branch, the pipelines triggered off of those will behave according to my rule, i.e. module-a will only be built when there was a change that affects it.
I would expect the same behaviour from the start.
I assume that "change" means "what git thinks has changed between this branch and the branch it was based off of". Is that not what change means in this context?
While searching for another answer I discovered by accident that Gitlab is working as designed in this case.
Is there a way to disable GitVersion using the branch name?
We had an inadvertent build number increment as the result of using a branch named: 3.16-changelist
The current build version was 3.16.0
After merging that branch it was: 3.16.1
That was unexpected. Wondering if that behavior can be disabled.
Thanks.
I want to run the gitlab-ci pages job only if the project is getting a new tag pushed. I already know that you can do this with:
only:
- tags
but the issue is that, if we ever push a tag for an older version (a backported bugfix or something) then this would overwrite the pages build. We tag using SEMVER if that helps
For example, what I'm trying to avoid is having a bug fix for an earlier version replacing the gitlab pages.
Let's say on the master branch we release version 1.5.0, this will build the pages for that version, and those will be the current documentation pages.
Now let's say we had to do a bugfix for version 1.3.0 to 1.3.1, if we make that bug fix and then push it, since pages builds on tags, it would build the docs for 1.3.1 and those would replace the docs for 1.5.0, which I want to avoid somehow.
GitLab CI allows to use regex patterns with only.
In your case, if you want your pipeline to be run only if a new tag is pushed, you should think of a naming convention for tags and find a regex that will only match these new tags. This should give you some ideas:
job:
only:
- /^(\d+\.)?(\d+\.)?(\*|\d+)$/
except:
- branches
- triggers
You need the except statement to specify that the job should only run when a tag is pushed. If you just added - tags to an only statement with a regex, it would run whenever a tag is pushed + when a branch or trigger matches the regex.
One possible solution would be to incorporate an beginning stage job that compares the latest tag and only sends success if the most recent pushed tag is the latest
stages:
- compare tags
- build
- test
- deploy
job:
stage: compare tags
only:
- <semver tag regex goes here>
except:
- branches
script: 'script-that-will-compare-all-semver-tags-to-CI_COMMIT_TAG-and-fail-if-not-latest'
job:
stage: build
...
job:
stage: test
...
...
the whole job should stop if the semver comparison fails
I have a ConcourseCI pipeline that automatically increments my version number using this resource type: https://github.com/concourse/semver-resource
My resource declaration looks like this:
- name: version
type: semver
source:
driver: git
initial_version: 0.0.1
uri: {{version-repo-uri}}
branch: {{version-repo-branch}}
file: {{version-file}}
private_key: {{git-key}}
And my job looks like this:
- name: increment-version
plan:
- get: {{git-repo-name}}
trigger: true
- get: version
params: {bump: patch}
- put: version
params: {file: version/version}
So as you can see, right now I'm always bumping PATCH version. However, I'd like an easy and preferably automated way for the pipeline to increment MAJOR, MINOR, PATCH, or RC version depending on the circumstances.
Is there a git hook or something similar that will know when to bump what? Any implementation best practices when automating semver into a pipeline? Any other Concourse resource-type I should be using instead? Or is this something we should definitely leave for a human to decide? And in that case, how to easily integrate that "manual" step into a CD pipeline?
The closest thing I can think of is having a version file in my project (committed to github) with the intended version, which will set MAJOR, MINOR, PATCH numbers. The pipeline picks ups that file, uses it as a base somehow, and only increments RC numbers, but this feels incredibly error prone.
To be clear, I'm not asking how to version releases in theory, and the meanings of what major, minor, or patch are. I'm asking in practice how to implement those recommendations listed on https://semver.org/.
My solution to this problem is to tag the commits, and a script which reads the Git commit message and steps the version based on the content:
If a version tag exist on the current commit: always step PATCH.
Else:
List all commits until the previous tag.
If any message contains "step: major" then step MAJOR
Else if all messages contain "step: patch" or "step: micro" then step PATCH
Else step MINOR
This means that if the committer does not state anything in the message, then the change is assumed to be a functional change.
Tag and push the commit before the built artifact is distributed. Otherwise the next build could produce an already existing version.
Just modify the logic as needed for your use cases.