Is there any unique number in Gitlab CI which can be used as build number as we use in Jenkins. I came to know about the variable "CI_PIPELINE_IID" but the problem with this variable is, it updates for all branches and there is no such variable exist for each branch.
We solved the same issue using the variable $CI_PIPELINE_IID, which is defined as
The project-level IID (internal ID) of the current pipeline. This ID is unique only within the current project.
And is quite similar to Jenkins' $BUILD_NUMBER
See also https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#variables-reference
It looks like CI_COMMIT_SHA or CI_COMMIT_SHORT_SHA are great candidates for this as they give you a reference to the commit it was built from.
For example, if you want to use it as a docker image tag, use
docker build . -t myapp:$CI_COMMIT_SHA
Note that earlier versions of Gitlab (version 8.x) use CI_BUILD_TAG
More variables on: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#variables-reference
You can check if any of the other ids "CI variables" might work in your case:
CI_JOB_ID 9.0 all The unique id of the current job that GitLab CI uses internally
CI_PIPELINE_ID 8.10 all The unique id of the current pipeline that GitLab CI uses internally (one I)
CI_PROJECT_ID all all The unique id of the current project that GitLab CI uses internally
CI_RUNNER_ID 8.10 0.5 The unique id of runner being used
Yeah,it's a reasonable request for many situations. Someone has issued it before, please refer to: https://gitlab.com/gitlab-org/gitlab/-/issues/23844. But it seems that it has not added this so far.
Related
I'm learning how to create releases with GitLab pipelines. GitLab recommends you use semantic versioning. However, I would like to create a release with a custom tag name. Specifically, I would like to include:
Month
Day of Month
Build number of the day
The final bullet is what is tripping me up. Is there a way in GitLab to include the build number of the day? Azure DevOps has a revision number variable. However, I don't see anything similar in GitLab. As I'm learning, I'm concerned I'm missing something. Thank you.
In GitLab, the rough equivalent for ADO's $Build.BuildNumber would be $CI_PIPELINE_IID. The $CI_PIPELINE_IID starts at 1 for the first pipeline and increments by one for every pipeline.
If you want a unique ID for each job (rather than pipeline) then $CI_JOB_ID is the closest thing. It will always go up, but it won't necessarily be sequential.
We have hundreds of similar projects in GitLab which have the same structure inside.
To build these projects we use a one common TeamCity build. We trigger and pass project GitLab URL along with other parameters to the build via API, so TeamCity build knows which exact project needs to be fetched/cloned. TeamCity VCS root accepts target URL via parameter.
The question is how to replace existing TeamCity build with a GitLab pipeline.
I see the general approach is to have CI/CD configuration file(.gitlab-ci.yml) directly in project. Since the structure of the projects the same this is not the option to duplicate the same CI/CD config file across all projects.
I'm wondering is it possible to create a common pipeline for several projects which can accept the target project URL via parameter ?
You can store the full CICD config in a repository and put in all your projects a simple .gitlab-ci.yml which includes the shared file.
With thus approach there is no redundant definition of the jobs.
Still, you can add specific other jobs to specific projects (in the regarding .gitlab-ci.yml files or define variables in a problem and use some jobs conditionally) - you can also include multiple other definition files, e.g. if you have multiple similar projects.
cf. https://docs.gitlab.com/ee/ci/yaml/#include
With latest GitLab (13.9) there are even more referencing methods possible: https://docs.gitlab.com/ee/ci/yaml/README.html#reference-tags
As #MrTux already pointed out, you can use includes.
You can either use it to include a whole CI file, or to include just certain steps. in Having Gitlab Projects calling the same gitlab-ci.yml stored in a central location - you can find detailed explanation with examples of both usages
We have multiple repos and whenever the developer runs the sonarQube scanner through Jenkins job, it is creating one project with build number along with the date, is there anyway I can re-use the same project name ..?
developers are running sonarQube reports through Jenkins jobs.
sonar.projectKey=portal1-sonar:1stiteration-${BUILD_NUMBER}
sonar.projectName=SonarQube nodeJS portal1 Build : ${BUILD_NUMBER}_${BUILD_TIMESTAMP}
anyway, I can change and use same project name, whenever developer runs sonarQube.
every project is defined in SonarQube with it's own key. That means if the key is the same, it is the same Project, and you will have a "history" of analyses and can compare parameters.
Although the idea of buildnumbers seems to be interesting, i recommend to use Branch names instead. There are currently two ways of doing this, for the first one, you need to have a SonarQube installation with a paid price. Than you are entitled to use the branch plugin. Which is actually the more superior way, because your project will show branches. The sonarQube docs are quiet helpful regarding this.
The old/Deprecated way will create a new project per branch, which you can than compare. the property you need to set is sonar.branch and this will be automatically added to your project key. So if the project key is Project and the sonar.branch is set to develop your new project will have the key Project:develop. This parameter is deprecated, and i am not sure, how long it will stay in the system.
I'm using GitLab pipelines and have defined my build defintion in the .gitlab-ci.yml file.
I'm using this to build docker containers.
Simple question. Is there a way I can tag my docker containers with either a semver from gitlab or a timestamp.
The build-in variables don't seem to give me much to work with.
On Windows I've been able to use GitVersion before in powershell that gets the semver tag and puts it into a variable you can use in the rest of the build process.
If I can't do that, is it possible to get a timestamp from the OS and use that in the yml file?
You can use the timestamp in your .gitlab-ci.yml like this (taken from our own usage creating <year>.<month> tags and releases:
job-1:
script:
- export VERSION=$(date +%y.%m)
- docker build -t myregistry/project/image:$VERSION
This results in a image tag like: myregistry/project/image:17.10
You can use date +%s instead of date +%y.%m for unixtimestamp.
Depending on your (git)flow you can also use branch-slugs provided by Gitlab CI env vars
Regarding timestamp, another approach is to use existing variables associated to your current pipeline.
See GitLab 13.10 (March 2021)
Predefined CI/CD variables for job start and pipeline created timestamps
Previously, if you wanted to reference the exact date and time when a job started
or a pipeline was created, you needed to retrieve these timestamps in your scripts.
Now they are readily available as predefined CI/CD variables by using CI_JOB_STARTED_AT and
CI_PIPELINE_CREATED_AT, provided in the ISO 8601 format and UTC time zone.
Thanks to #Winkies for this contribution!
See Documentation and Issue.
Unfortunately this variable can't be used directly as an image tag. As seen in the referenced implementation issue, the output of this variable is similar to 2021-03-18T04:45:29Z. Used directly, your image would look something like myimage:2021-03-18T04:45:29Z which is invalid.
I can't find out how to access variables in a build-script provided by the gitlab-ci.yml-file.
I have tried to declare variables in two ways:
Private Variables in the Web-Interface of GitLab CI
Variable overrides/apennding in config.toml
I try to access them in my gitlab-ci.yml-files commands like that:
msbuild ci.msbuild [...] /p:Configuration=Release;NuGetOutputDir="$PACKAGE_SOURCE"
where $PACKAGE_SOURCE is the desired variable (PACKAGE_SOURCE) but it does not work (it does not seem to be replaced). Executing the same command manually works just as expected (replacing the variable name with its content)
Is there some other syntax required i am not aware of?
I have tried:
$PACKAGE_SOURCE
$(PACKAGE_SOURCE)
${PACKAGE_SOURCE}
PS: Verifying the runner raises no issues, if this matters.
I presume you are using Windows for your runner? I was having the same issue myself and couldn't even get the following to work:
script:
- echo $MySecret
However, reading the Gitlab documentation it has an entry for the syntax of environment variables in job scripts:
To access environment variables, use the syntax for your Runner’s shell
Which makes sense as most of the examples given are for bash runners. For my windows runner, it uses %variable%.
I changed my script to the following, which worked for me. (Confirmed by watching the build output.)
script:
- echo %MySecret%
If you're using the powershell for your runner, the syntax would be $env:MySecret
In addition to what was said in the answer marked as correct above, you should also check whether your CI variables in the gitlab settings are set as "protected". If so, you may not be able to use them in a branch that's not protected.
"You can protect a project, group or instance CI/CD variable so it is only passed to pipelines running on protected branches or protected tags." -> check it https://docs.gitlab.com/ee/ci/variables/index.html#protect-a-cicd-variable
Be aware that.. in certain cases SOME of the variables Gitlab CI CD offer are not always available..
In my case I wanted to use ${CI_COMMIT_BRANCH} but if you read the doc
https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
The commit branch name. Available in branch pipelines, including pipelines for the default branch. Not available in merge request pipelines or tag pipelines.