Jenkins using File Parameter with MultiJob Project - linux

I am using the MultiJob Project in order to implement a process the runs every time there is a push to a certain Git branch.
How can I pass parameters between 2 different jobs (each job is located in a separate MultiJob Phase)
What i tried to do is:
Job A: (Run on the Master - windows)
echo 2 parameters into a new file (Called parameters.properties) that i placed in a shared location (not in the workspace of Job A)
so this file's contnet looks like:
currentBuild=2012-11-27_09-20-50
currentBranch=master
Job B: (Run on a Linux Slave)
The option of "This build is parametrized" is on.
Added "File Parameter" and only the file name as I also set a custom workspace to the shared location where the file is located.
The i have a shell script that tries to use this parametrs but it doesnt get it.
Please Assist,
Doron

The Solution:
in the MultiJob Main Project:
Set "This build is parametrized"
Add 2 Text Parameters (different names since the Job Build is based on Jenkins variable Build_Id which is changed and i want later to set the currentBuild to a constant value and not to a new one)
JobBuild
JobBranch
On each Job under each MultiJob Phase:
Add Predefined Parameters:
currentBuild=${JobBuild}
currentBranch=${JobBranch}
untick the "Current job parameters"
untick the Exposed SCM"

Related

Set global variable value within a job in gitlab yml file

I have two jobs : first one is "test" and the second one is "push". test job is allowed to fail (allow_failure: true) I only wanna run the push job if the test job is success.
One option is to save the variable to a file and use it through artifact. But what I'm interested in is that is if there's a way achieving this without the file, like having global var and update the value in the test job if it's a success, but apparently modifying global variables from the job scope is not possible. Any suggestions?

How to read labels in Gitlab CI script

I have a few use cases in my Gitlab setup I would like to be able to support:
If a certain label (let's call it “skip_build”) is set, the deployment steps should not be run when I merge an MR to a main branch. This would be useful when we have multiple MRs being merged right after another and only need the last one built.
If another label (we'll call it “skip_tests”) is set, I should be able to read it as an env var from within the script and alter the flow within the script accordingly (using normal bash syntax), e.g. to alter the package command parameters used a bit. This is useful for small changes where it might not make sense to run a lengthy test suite.
Is this possible with Gitlab, and if so, how?
I’ve tried experimenting with CI_MERGE_REQUEST_LABELS, but it doesn’t seem to be able to read that as an env var from within the script.
You have to use merge request pipelines for the CI_MERGE_REQUEST_LABELS variable (and other MR-related variables) to be present as documented in predefined variables.
You could use a rules: clause to skip jobs. Something like
build:
rules: # only run this job if the regex pattern does not match
- if: $CI_MERGE_REQUEST_LABELS !~ /skip_build/
You can also do this on any other kind of predefined (or user-defined) variable, like branch name, commit messages, MR titles, etc. Whatever works for you.
For example, a built in feature of GitLab is that if your commit message contains [ci skip] it will prevent the pipeline from running. You could implement similar functionality for your jobs and/or pipelines through rules: or workflow:rules:.

Gitlab CI don't test if there are no changes to the code (pytest-testmon)

I want to perform tests using gitlab CI using pytest-testmon. Unfortunately it seems that the generated file .testmondata is not saved in the gitlab-runner instances, so that no recollection of what was tested is saved.
Is there a way of saving this .testmondata and using it (for every different branch at test) in order to avoid repeating tests of unchanged code when code is pushed to those branches?
You can upload files generated during your job to Gitlab so you can view them later by downloading them, viewing on a Merge Request, or using them in other jobs by using the artifacts keyword. Here's a simple example:
tests:
stage: tests
script:
- ./run_tests.sh
artifacts:
paths:
- .testmondata
name: "$CI_COMMIT_REF_NAME_tests_testmondata"
expose_as: 'Tests Results'
expire_in: 3 months
In this example, after your script section (and before_script or after_script if present) runs, gitlab-runner will look for a file/directory that matches the entries in the paths array. If none are found, it will throw an error.
The runner will then upload the artifacts to Gitlab using the name in the name field. It's good practice to use some of the predefined variables that Gitlab CI provides so you can easily identify which pipeline and job an artifact came from, if necessary. In this example the name has the branch or tag name, and then _tests_testmondata.
The next attribute, expose_as lets you put a link on a Merge Request for this branch to display the artifacts. Without expose_as, you'll have to open the Pipeline and Job to view the artifacts.
Next, expire_in lets you define when the artifacts from this job should expire. If you don't set this attribute, the artifacts will expire based on the Gitlab server's setting, which by default is 30 days. You can supply a number of seconds as an int (3600, or one hour), never (to never expire), or many other human-readable formats like 3 years 8 months 28 days or 46 months.
You can view all the available predefined variables here: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html, and you can view all the options for the artifacts keyword here: https://docs.gitlab.com/ee/ci/yaml/#artifacts

Jenkins fails on periodic build with Dynamic Choice Parameter Groovy script

I'm trying to use the Dynamic Choice Parameter plugin to set up a parameterized build in Jenkins. The parameters should be the names of some directory's in a directory of the working directory of the job (i.e. /var/lib/jenkins/workspace/JobName/dirToScan/).
Making the items in the drop down menu can be done in this way:
def list = ['ls', "/path/to/dirToScan/"].execute().text.tokenize()
To reach the right directory, I need the name of the job since, as opposed to when a job is executed, the directory in which the this is done is not the /var/lib/jenkins/workspace/[Job Name]/ directory but the root dir /.
The Dynamic Choice Parameter plugin allows the execution of a Groovy script to fill the choice parameter. Using the answer provided here I was able to retrieve the job name. So my final code to build the drop-down menu in the parameterized build menu in Jenkins looks like this:
def build = Thread.currentThread().toString()
def regexp= ".+?/job/([^/]+)/.*"
def match = build =~ regexp
def jobName = match[0][1]
def list = ['ls', "/var/lib/jenkins/workspace/" << jobName << "/dirToScan"].execute().text.tokenize()
Clicking the Build with Parameters link in the Jenkins job opens the page with the drop-down menu (which I named Restore) and also the actual building works great!
But now comes my problem:
If set the job to be build periodically, the build fails with the following console output:
Started by timer
Building in workspace /var/lib/jenkins/workspace/JobName
FATAL: Null value not allowed as an environment variable: Restore
java.lang.IllegalArgumentException: Null value not allowed as an environment variable: Restore
at hudson.EnvVars.put(EnvVars.java:356)
at hudson.model.StringParameterValue.buildEnvironment(StringParameterValue.java:56)
at hudson.model.ParametersAction.buildEnvVars(ParametersAction.java:88)
at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:929)
at hudson.plugins.mercurial.MercurialSCM.checkout(MercurialSCM.java:533)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1270)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
at hudson.model.Run.execute(Run.java:1750)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Finished: FAILURE
This does not happen if I just populate the drop-down menu in a 'normal' way, e.g.: def list = ["Option 1", "Option 2", "Option 3"]
This might be a bug in the plugin, or Jenkins being unable to execute the Groovy code if it starts a job by itself. The problem only occurs with a periodic build, not if I start the build myself and it it independent of the chosen option in the drop-down menu. Does anyone have an idea on how to fix this?

TFS Build - Can I create a new branch and add the new mapping to my workspace dynamically?

As part of our CI, after each release we create a new branch and manually change the version number in our AssemblyInfo and Config files. This is prone to human error and we have decided to automate this process. So far I have a script that creates a new branch from our Main branch which I run before our build; the XAML has been modified with a number of activities that checks out all the AssemblyInfo and config files, updates the version numbers and checks the changes in.
What I want to do is to make this two stage process into a single process. The idea I have at the moment is to add the "TF Branch" script as an invoke process at the beginning of my template before the "initialize Workspace" sequence; this will create the new branch (say branches\1.2.3.4). After the branch has been created I then use a "TFWorkFold" activity placed just under "Create Workspace", in the TFWorkFold activity I add the new mapping - ( ServerPath = $\TeamProject\Branches\1.2.3.4 - LocalPath = SourcesDirectory) but when the process hits the "Get Workspace" activity none of the source files from the new branch are added to the Workspace.
When I run this on other builds the new mapping is successful, only if the branch has been created before the build is initialized.
Is there a step i'm missing? In my Create branch script i have a ping timer of 600secs to allow the branching enough time to complete before the new workspace mapping is added
Figured it out,
After the new branch is created the build process needs to get the latest source files created. In the Build definition I need to tell it to get the Latest Version, this is set in the "Process" section under "Advanced" then "Get Version" I set the value as "T" for "Get Latest". Done :)

Resources