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?
Related
I need to exclude a job from pipeline in case my project version is pre-release.
How I know it's a pre-release?
I set the following in the version info file, that all project files and tools use:
version = "1.2.3-pre"
From CI script, I parse the file, extract the version value, and know whether it's a pre-release or not, and can set the result in an environment variable.
The only way I know to exclude a job from pipeline is to use rules, while, I know also from gitlab docs that:
rules are evaluated before any jobs run
before_script also is claimed to be called with the script, i.e. after applying the rules.
I can stop the job, only after it starts from the script itself, based on the version value, but what I need is to extract the job from the pipeline in the first place, so it's not displayed in the pipeline history. Any idea?
Thanks
How do you run (start) your pipeline, and is the information whether "it's a pre-release" already known at this point?
If yes, then you could add a flag like IS_PRERELEASE as a variable to the pipeline, and use that in the rules: section of your job. The drawback is that this will not work with automatic pipelines (triggered by a commit or MR); but you can use this approach with manually triggered pipelines (https://docs.gitlab.com/ee/ci/variables/#override-a-variable-when-running-a-pipeline-manually) or via the API (https://docs.gitlab.com/ee/ci/triggers/#pass-cicd-variables-in-the-api-call).
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:.
I want to set the value of a variable based on whether loading from a cache has succeeded.
I plan to set the variable using an if statement, the same way they do in this example: https://docs.gitlab.com/ee/ci/yaml/#workflowrulesvariables
(The link goes to the wrong part of the page: search for Example of workflow:rules:variables )
If my yaml looks like this:
cache:
key: $CI_COMMIT_REF_SLUG
paths:
- pathtocache
How can I check if pathtocache exists?
This isn't possible due to the lifecycle of when rules are evaluated, which is before the cache/artifacts are restored. Keep in mind the rules can be used to define whether or not the job runs, so they are evaluated at pipeline start before any jobs have been run and thus before you would have generated any cache files.
If you want to test whether the cache has been populated then branch your job's logic based on that, you will have to do so within the script block for your job.
Am I able to pass value from variable that I created in one job to next job so I can do some checks of that value in next job of the same stage ?
I would like to have first job that creates some variable and then assigns value to that variable and next job, in same stage that would do check of that value ? I need this for specific use case in my pipeline ?
I was going through the documentation on GitLab and I couldn't find any recource that would help me with solving this case ?
Any help with this would be really appreciated. Thanks a lot! :)
Yes, you do this by using the dotenv file artifact. You'll create a file in one job that has a set of values in it like this:
FIRST_VAR=1234
SECOND_VAR=hello_world
Then set that as a dotenv type artifact according to the documentation, and that will make downstream jobs have those variables be set.
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"