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.
Related
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?
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}%).
In my GIT based project, I need to set several environmental variables which is required by build scripts and many other ant targets.
For now I have a shell script which will export variables but each time a user opens a new bash window, he will need to repeat the steps by executing the shell script in order to set the environmental variables.
Most of these variables are user machine/env dependent and these are evaluated on the fly by shell before being exported.
If there a way to make it more dynamic. I understand that GIT provides hook and one possibility is that I can use hook to call the shell when user checkouts to a branch.
But here again GIT persists the current working branch and if user goes to a new bash window he would continue to be in previously chosen branch and he might not call git checkout branch, and which eventually will not call env variables shell.
So what is the best of handle this ?
I usually version a build wrapper script used by the user for launching the build (in the current or in a new shell window)
That way, the environment variables are always set at each build.
Furthermore, by versioning that build.sh/build.bat wrapper script, you keep the knowledge of which options/environment variable your project needs in order to be built.
That wrapper script, if changed, is versioned and can be audited (git blame): you know who changed what and when.
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.
I understand how to use the EnvInject plugin to compute variables from string parameters (the parameter name simply is an unbound variable in the groovy script performing the injection).
I want to use a Run Parameter - the parameter that contains the latest successful build of a project (or whichever build the user selects), but it appears that any of those are not available at the time the EnvInject plugin runs.
I guess I need to write groovy code to inspect the desired project myself and get the right build name directly from the model - except I can't do that, since the model lives on the master and the envInject plugin runs on the slave....
EnvInject can run at different times...
At node/master level (on startup, and available always).
At job startup, before SCM step (configured at the top of job configuration).
After SCM step (configured under "build environment" section).
As a build step.
You should either last or second-last options, if you want build parameters to be available
Lastly, there is another option to try. Get pre-scm-buildstep plugin. This allows to run any build step (including EnvInject), just before the SCM checkout. I've done a quick test, and the job parameters and their values are available at this stage.