I wonder if it's possible to show a custom warning next to a Gitlab-CI job.
For example, I'd like in a single job to lint and style check a terraform configuration, print a warning if it doesn't pass, then create a terraform plan and stop the pipeline if that fails.
Is this feasible?
Turn on allow_failure (or set custom exit_codes) and exit with listed exit_codes. This will show a warning icon without blocking the pipeline.
test_job_2:
script:
- echo "Run a script that results in exit code 137. This job is allowed to fail."
- exit 137
allow_failure:
exit_codes:
- 137
- 255
Ref: https://docs.gitlab.com/ee/ci/yaml/#allow_failure
Related
In my yaml, i am trying to use the allow_failure:exit_codes: feature:
job name:
script:
- ...
rules:
- when: manual
allow_failure:
exit_codes:
- 1
- 2
- 3
GitLab mark invalid yaml in tag: allow_failure:exit_codes
In the documentation in gitlab, i found version history:
Version history
Introduced in GitLab 13.8.
Feature flag removed in GitLab 13.9.
How can I resolve this error?
Your GitLab version is 13.2.6 but the feature was introduced in GitLab 13.8, therefore you won't be able to use this feature unless you upgrade your GitLab instance to an applicable version.
As a possible alternative you can manually check error codes in your script. This works best if you run your script steps as a script run with bash (as opposed to directly in job steps).
With GitLab Runner version 13.12 or higher, you can use the FF_USE_NEW_BASH_EVAL_STRATEGY feature flag and have bash traps work in inline steps... you can do something like this and not need to create a script file:
MY_JOB:
variables:
FF_USE_NEW_BASH_EVAL_STRATEGY: "1" # needed to make `trap` work with inline scripts
# only available with GitLab runner 13.12+
# It's usually OK to use runners at higher minor version than the GitLab server
script:
- |
cleanup() {
rv=$?
echo "return code was $rv"
if [[ $rv -eq 3 ]]; then # simulate behavior of `allow_failure:exit_codes:[3]`
echo "return code ${rv} is allowed. Exiting 0"
exit 0
fi
exit $rv
}
- trap "cleanup" EXIT
- /bin/false || exit 3 # throw exit code 3
I have a GitLab CI/CD Job with the following definition:
compile:
stage: compile
tags:
- windows
- powershell
- bl653_8dc0_1053
artifacts:
paths:
- main.linenumbers.uwc
script:
- XComp_BL653_8DC0_1053.exe .\main.linenumbers.sb
- Test-Path -Path .\main.linenumbers.uwc
When the job executes, the XComp_BL653_8DC0_1053.exe application fails and returns exit code 7. However, the build still succeeds even though there was a non-zero exit code and no artifacts.
Executing "step_script" stage of the job script
00:02
$ XComp_BL653_8DC0_1053.exe .\main.linenumbers.sb
OnEvent EVTMR2 call HandlerTimer2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Compile Error: (0x0453) TOK_UNKNOWN_EVENTFUNC
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
File : main.linenumbers.sb
Line : 110
Source : OnEvent EVTMR2 call HandlerTimer2
: ----------------------------------^
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Uploading artifacts for successful job
00:01
Version: 14.3.2
Git revision: e0218c92
Git branch: 14-3-stable
GO version: go1.13.8
Built: 2021-09-30T16:11:30+0000
OS/Arch: windows/amd64
Uploading artifacts...
Runtime platform arch=amd64 os=windows pid=7216 revision=e0218c92 version=14.3.2
WARNING: main.linenumbers.uwc: no matching files
ERROR: No files to upload
Job succeeded
I can see that it never runs the Test-Path line, so it is correctly exiting when the non-zero exit code happens, but why is it saying the build passes?
I'm using GitLab EE version 14.9. My runner is a PowerShell Executer on Windows 10.
This behavior is an artifact of how powershell works. The script will continue even if a command fails and the overall exit code for the script (and job) will be the exit code of the last command.
To ensure a command failure in XComp_BL653_8DC0_1053.exe causes the job to stop and exit, you would want to do something like:
script:
- |
XComp_BL653_8DC0_1053.exe .\main.linenumbers.sb
if(!$?) { Exit $LASTEXITCODE }
You can see this pattern repeated a lot in the internal powershell scripts used by the runner.
You can also set the $ErrorActionPreference = "Stop" to change this behavior for powershell cmdlets (not necessarily .exes). This can be done in an environment variable:
variables:
ErrorActionPreference: STOP
For additional context, see:
How to stop a PowerShell script on the first error?
Why are my PowerShell exit codes always "0"?
I have a GitLab CI/CD job doing some stuff.
I want some executed commands to be able to fail and result in a warning for this job, but I also want other command to result in an error in the pipeline if they fail.
I have set in the .yaml file allow_failure: true, which will always result in a warning for this job regardless of the error.
Can I tell GitLab job to output an error for a specific exit code and a warning for another ?
With gitlab 13.9 allow_failure:exit_codes where introduced. With that you can now allow failure for certain exits codes and fail the job for all other ones.
allow_failure:
exit_codes:
- 137
- 255
I have a job in my pipeline that has a script with two very important steps:
mvn test to run JUnit tests against my code
junit2html to convert the XML result of the tests to a HTML format (only possible way to see the results as my pipelines aren't done through MRs) that is uploaded to GitLab as an artifact
docker rm to destroy a container created earlier in the pipeline
My problem is that when my tests fail, the script stops immediately at mvn test, so the junit2html step is never reached, meaning the test results are never uploaded in the event of failure, and docker rm is never executed either, so the container remains and messes up subsequent pipelines as a result.
What I want is to be able to keep a job going till the end even if the script fails at some point. Basically, the job should still count as failed in GitLab CI / CD, but its entire script should be executed. How can I configure this?
In each step that you need to continue even if the step fails, you can add a flag to your .gitlab-ci.yml file in that step. For example:
...
Unit Tests:
stage: tests
only:
- branches
allow_failure: true
script:
- ...
It's that allow_failure: true flag that will continue the pipeline even if that specific step fails. Gitlab CI Documentation about allow_failure is here: https://docs.gitlab.com/ee/ci/yaml/#allow_failure
Update from comments:
If you need the step to keep going after a failure, and be aware that something failed, this has worked well for me:
./script_that_fails.sh || FAILED=true
if [ $FAILED ]
then ./do_something.sh
fi
Having in gitlab-ci a job like the following one:
static_test_service:
stage: test code
script:
- docker run --rm -v $(pwd):/data -w /data dparra0007/sonar-scanner:20171010-1 sonar-scanner
-Dsonar.projectKey=$CI_PROJECT_NAMESPACE:$CI_PROJECT_NAME
-Dsonar.projectName=$CI_PROJECT_NAME
-Dsonar.branch=$CI_COMMIT_REF_NAME
-Dsonar.projectVersion=$CI_JOB_ID
-Dsonar.sources=./greetingapi/src
-Dsonar.java.binaries=./greetingapi/target
-Dsonar.gitlab.project_id=$CI_PROJECT_ID
-Dsonar.gitlab.commit_sha=$CI_COMMIT_SHA
-Dsonar.gitlab.ref_name=$CI_COMMIT_REF_NAME
I would need to fail the gitlab job when the sonarqube analysis fails. But in that case, the error in analysis is reported but not sending a fail status to the job in Gitlab CI and the step always finish with success.
It seems that there is no way to raise any event from "docker run" to be managed by gitlab job.
Any idea on how to force to fail the job if the sonarqube analysis fails?
Thanks,
To break the CI build for a failed Quality Gate, you have write script based on the following steps
1.Search in /report-task.txt the values of the CE Task URL (ceTaskUrl) and CE Task Id (ceTaskId)
2.Call /api/ce/task?id=XXX where XXX is the CE Task Id retrieved from step 1 Ex:- https://yourSonarURL/api/ce/task?id=Your ceTaskId
3.Wait for sometime until the status is SUCCESS, CANCELED or FAILED from Step 2
4.If it is FAILED, break the build (Here failure is unable to generate sonar report)
5.If successful,then Use the analysisId from the JSON returned by /api/ce/task? id=XXX(step2)and Immediately call /api/qualitygates/project_status?analysisId=YYY to check the status of the quality gate.
Ex:- https://yourSonarURL/api/qualitygates/project_status?analysisId=Your analysisId
6.Step 5 gives the status of the critical, major and minor error threshold limit
7.Based on the limit break the build.
I faced this problem with GitLab and Sonar where Sonar was failing the QualityAnalysis but GitLab job was still passing with
INFO: ANALYSIS SUCCESSFUL, you can find the results at:
Now the problem is below missing config in sonar.properties
sonar.qualitygate.wait=true
sonar.qualitygate.timeout=1800
So basically, the SonarScan takes time to do the analysis and by default it won't wait for the analysis to complete and may returns default SUCCESSFUL ANALYSIS result to GitLab
With the mentioned configuration, we are explicitly asking GitLab to wait for the qualitygate to finish and gave some timeout as well (in case analysis takes long time to finish)
Now we see the GitLab job fails with below
ERROR: QUALITY GATE STATUS: FAILED - View details