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.
Related
We are using Gitlab Community Edition 8.15.2 and are using custom global git hooks for all our repos (i.e. all repos use the same hooks).
For one of our repos, I want to use a <project>.git/custom_hooks hooks and NOT the global hooks.
According to the Gitlab documentation for chained git hooks (https://docs.gitlab.com/ce/administration/custom_hooks.html) it's going to go through all the possible locations and execute as long as the previous ones successfully exit.
I don't want it to execute both the custom_hooks and the global hooks...just the custom one. Is this possible?
The problem is, after gitlab-shell merge_requests 93, that <project>.git/hooks/ is a symlink to gitlab-shell/hooks global dir.
So if you want to be sure to not use global hooks, you would either
change the symlink to an empty folder (but that might have side-effects if gitlab-shell expects to run for instance a common global pre-reveive or update hooks)
change the global scripts in order to detect the Git repo they are executed in, and exit immediately (with status 0) if the repo matches one you don't want global hooks.
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.
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.
I need to dynamically modify the notification e-mail recipients based on the build, so I'm using a groovy script. I want this script to be available to all jobs, so I want it to reside on the Jenkins file system and not within each project. It can be either in the recipients fields (using ${SCRIPT,...}) or in the pre-send script. A short (fixed) script that evaluates the master script is also good, as long it is the same for all projects.
You should try Config File Provider plugin. It works together with the Credentials configuration of Jenkins.
Go to Manage Jenkins > Managed files
Click Add a new Config
Select Groovy file
Enter the contents of your script
Your script will now be saved centrally on Jenkins, available to master/slave nodes.
In your Job Configuration:
Under Build Environment
Check Provide Configuration file
Select your configured groovy File from dropdown
Set Variable with a name, for example: myscript
Now, anywhere in your job, you can say ${myscript} and it will refer to absolute location of the file on filesystem (it will be somewhere in Jenkins dir).
My impression it that you would probably want to completely switch to Jenkins pipelines where the entire job is groovy file (Jenkinsfile) in the root of the repository.
Email-Ext already supports it even if it may be lacking some documentation.
https://jenkins.io/doc/pipeline/steps/email-ext/