Menu
I recently started implementing automatic tests for my code, and I noticed that the CI does not catch the warnings of the compiler - the tests are shown as successful even when there are warnings.
I have initially added a flag for the compiler to turn the warnings into errors and allow_failure=True, but the problem is that the compiler stops in the first warning->error and does not go through the entire compilation.
I then used the trick explained here to write the warnings into a file, and then test if the file is not zero:
- make 2> >(tee make.warnings)
- test ! -s make.warnings
After the whole compilation is done, this will give an error if there are warnings written to the file - and using allow_failure=True, this works for the cases where I have no errors/warnings, but also when I have warnings. However, if I have real errors, this will also be shown as a warning in CI, and will not stop the pipeline because of the allow_failure=True.
I could not find a way to allow_failure=True depending on something run in the script (without creating a new stage) or using some condition (i.e., if the file is empty or not). Is there a simple way to do this that I'm missing?
695
Gitlab CI Rules Except Sometimes, we only focus on a scenario where we don't want to execute a job. And to define a rule to skip a job, we can use except keyword. In the example above, we are skipping the job (lint) when the commit was triggered using an API call.
These are scripts that you choose to be run before the job is executed or after the job is executed. These can also be defined at the top level of the YAML file (where jobs are defined) and they'll apply to all jobs in the . gitlab-ci. yml file.
In the gitlab documentation you find a list of predefined variables HERE, where the variable CI_PIPELINE_SOURCE is explained to have the possible values "push, web, schedule, api, external, chat, webide, merge_request_event, external_pull_request_event, parent_pipeline, trigger, or pipeline."
You can set the GIT_STRATEGY used for getting recent application code, either in the global variables section or the variables section for individual jobs. If left unspecified, the default from project settings will be used. There are three possible values: clone , fetch , and none . clone is the slowest option.
Introduced in GitLab 12.8. Use allow_failure: true in rules: to allow a job to fail without stopping the pipeline. You can also use allow_failure: true with a manual job.
If the artifacts of a dependent job are expired or deleted, then the job fails. Use artifacts to specify a list of files and directories that are attached to the job when it succeeds, fails, or always . The artifacts are sent to GitLab after the job finishes.
Introduced in GitLab 12.3. Use interruptible if a job should be canceled when a newer pipeline starts before the job completes. This keyword is used with the automatic cancellation of redundant pipelines feature. When enabled, a running job with interruptible: true can be cancelled when a new pipeline starts on the same branch.
If the rule matches, then the job is a manual job with allow_failure: true . The rule-level rules:allow_failure overrides the job-level allow_failure , and only applies when the specific rule triggers the job. Introduced in GitLab 13.7.
Since there is no condition per se, check out GitLab 13.8 (January 2021):
Control job status using exit codes
You can use the
allow_failurekeyword to prevent failed jobs from causing an entire pipeline to fail.Previously,
allow_failureonly accepted boolean values oftrueorfalsebut we’ve made improvements in this release.Now you can use the
allow_failurekeyword to look for specific script exit codes.This gives you more flexibility and control over your pipelines, preventing failures based on the exit codes.
See Documentation and Issue.
If you can use as condition an exit status of a script, that would be enough for allow_failure to be more specific.
105
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
