How do I know it's the first run of a pipeline for a new branch?
On systems like Jenkins there is a BUILD_NUMBER environment variable. On the first run the variable will be 1.
I have specific logic that should only be executed if it's the first build of a new feature branch.
Bitbucket's "build numbers" are always unique though: https://bitbucket.org/blog/bitbucket-pipelines-can-count-builds-numbered
Does Bitbucket provide a way to know if it's the first run of a build? Or is there some environment variable that tracks the current run number?
Related
I am really new to Git & GitLab. My aim is to create few CICD jobs which should run when a commit happens on a particular branch. I was going through few topics & videos for the last 2 weeks and come up with yaml file which actually runs now and build some files. My current requirement is to get few parameters like the commited branch name, commited files and then download these files to a remote system. I have gone through the CICD variables and tried to echo these variables to see the values.
echo $CI_COMMIT_REF_NAME simply echoes the value $CI_COMMIT_REF_NAME in the CICD job console.
How can we get this value? Any pointers is highly appreciated.
Thanks in advance!
From your .gitlab-ci.yml file, it looks like you're in a Windows environment and should be using a different environmental variable.
Eg, $CI_COMMIT_REF_NAME should in fact be %CI_COMMIT_REF_NAME%
bash/sh $variable
windows batch %variable%
PowerShell $env:variable
See using CI variables in your job script.
I am trying to create a JS utility to version stamp a VSTS build with details about the branch and commit id.
I have been using git-rev-sync which works fine locally. However, when the code is checked out using a VSTS build definition, the repo is detached, and I am no longer able to determine from the git repo itself which branch the current code belongs to.
git-rev-sync reports something along the lines of:
Detatched: 705a3e89206882aceed8c9ea9b2f412cf26b5e3f
Instead of "develop" or "master"
I may look at the vsts node SDK which might be able to pick up VSTS environmental variables like you can with Powershell scripts.
Has anyone done this or solved this problem in a neater way?
The build variables will be added to current process’s environment variables, so you can access Build.SourceBranchName build-in variable from environment variable:
PowerShell:
$env:BUILD_SOURCEBRANCHNAME
NodeJS:
process.env.BUILD_SOURCEBRANCHNAME
Shell script:
$BUILD_SOURCEBRANCHNAME
Batch script:
%BUILD_SOURCEBRANCHNAME%
You also can pass it through argument of task ($(Build.SourceBranchName)), for example, using Replace Tokens task to replace variable value to a file, then you can read the value from the file (replace %{BUILD_SOURCEBRANCHNAME}%).
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.
Where does the Job script runs? Does it run on the same system as of Runner?
How the runner runs the script, and where does build get saved?
It would be great, if someone could explain the whole flow of Gitlab CI.
Yes, your jobs' scripts run on the same system as the runner. But before I go deeper, we need to discuss terminology. My team has run into issues before because the term 'runner' is overloaded. Humans typically use 'runner' to mean two different things:
A server on which the gitlab-ci exe is located
A gitlab-ci runner
The former should be self-explanatory; when you want to create a gitlab-ci runner, the first thing you do is provision a VM and put the exe on it somewhere.
The latter takes some explanation. gitlab-ci runners are not like Jenkins slaves; they're not entire servers. Instead, gitlab-ci runners act like a combination of workspaces and Jenkins labels. In other words, gitlab-ci runners combine a server, a gitlab instance, an execution environment and a set of tags. It is entirely possible, and in fact normal, to have multiple gitlab-ci runners on the same server.
The job script is completely decoupled from either type of runner (by 'job script' I assume you mean code called from a .gitlab-ci.yml file). Anything you call from that .gitlab-ci.yml, and in fact the script elements within it, will be executed
By a runner matching the tags configured for the job running the script
On the server on which that runner is installed
In a shell or Docker or Vagrant container, depending on the runner
Finally, the build is saved on the on which the runner is installed. the location will depend on the folder into which you dropped the gitlab-ci executable. Otherwise, jobs are stored on the file system in a manner reminiscent of Jenkins workspaces.
I wonder where I can use build environment variables in the job configuration.
For example:
At the "Source Code Management" I can use them.
At the "Trigger/call builds on other projects" sections "Predefined parameters" I can't use them, because they aren't resolved.
I don't find any scheme behind this. Is this depending on the plugin behind the build configuration section? (Git Plugin etc.)
I have one Job doing some stuff and generating a value within a groovy system script that is injected in the build environment.
def pa = new ParametersAction([
new StringParameterValue(key, value)
])
Thread.currentThread().executable.addAction(pa)
This value is needed as a build parameter of the called next build in the chain and used in this build job as the branch to be checked out.
But I don't know how to configure this.
You could make both those builds run on the same slave and and set the env variables on the slave in the first build. This env var then can be used by the downstream builds.