Expecting:CI need to trigger build and test then it should scan for dependencies vulnerability
Current Behaviour CI trigger but only run build and test not running Dependency-Scanning.gitlab-ci.yml
stages:
- build
- test
build:
stage: build
script:
- echo "Building"
test:
stage: test
script:
- echo "Testing"
include:
- template: Dependency-Scanning.gitlab-ci.yml
Dependency-Scanning.gitlab-ci.yml can be found in the following URL
https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/Dependency-Scanning.gitlab-ci.yml
You can try moving it to the top of the file. Works for me.
Can you toss the error in your post? Are you getting something like this if you use the CI linter? https://gitlab.com/amishpanda/cheatsheet/-/ci/lint
Found errors in your .gitlab-ci.yml:
dependency_scanning job: stage parameter should be .pre
setup
build
.post
You can also test your .gitlab-ci.yml in CI Lint
Related
UPDATE: added when:always under artifacts fixed the issue, since the unit tests were failing, so the coverage folder was not created as an artifact
When unit tests are run, a coverage folder is created. I want to save that coverage folder as an artifact in the pipeline so that sonarqube can access the reports in that folder to give an accurate coverage report. When I push up any code, I'm not seeing the coverage folder being saved as an artifact after the unit tests are run in the pre-build stage, so it is not being passed along to sonarqube in the build stage.
This is the yml file:
stages:
- Pre-Build
- Build
- etc.
Unit Tests:
stage: Pre-Build
allow_failure: true
script:
- npm ci
- npm run test
artifacts:
paths:
- coverage
when: always
SonarQube:
stage: Build
needs: ['Unit Tests']
except:
refs:
- tags
try add slash in dir-path
Unit Tests:
stage: Pre-Build
allow_failure: true
script:
- npm ci
- npm run test
artifacts:
paths:
- coverage/
when: always
I have a gitlab pipeline running on a windows machine with Windows 7 and powershell 4.0.
The .yaml has the typical 3 stages: build, test and deploy.
For the second stage I want to perform some simple tests that generate a log file which should be available after the test stage finishes.
Here the script section from the test:
script:
- '$exitCode = (start-process C:\app_versions\app_20181211\bin\app.exe -PassThru -Wait).ExitCode'
- 'cat .\TestLogs\BasicFunctionsTestPlan.log'
- 'exit $exitCode'
artifacts:
paths:
- .\TestLogs
expire_in: 1 year
Here I had one problem, after the test run has finished the stage finishes always successfully even if the test themselves failed. Then I had to force the script exit with an error code in case the application tells me that the tests failed.
This caused the second problem: the artifacts link do not get created even they are available (my test produce it anyway).
Probably if I knew how to tell gitlab that the test failed in a more clean way, the artifacts would be available anyway.
I agree that the log file is not an artifact but I would like to keep that file in order to check how the tests have performed, maybe there is a better way to save this file.
Thanks in advance for your help!
EDIT:
Looks like there were more people having the same issue here, maybe it helps understanding better the problem.
I had the same question, but it's easily solved:
You can use artifacts:when to upload artifacts on job failure or despite the
failure.
artifacts:when
source: Gitlab CI yaml reference: artifacts:when
Introduced in GitLab 8.9 and GitLab Runner v1.3.0.
artifacts:when is used to upload artifacts on job failure or despite the
failure.
artifacts:when can be set to one of the following values:
on_success - upload artifacts only when the job succeeds. This is
the default.
on_failure - upload artifacts only when the job
fails.
always - upload artifacts regardless of the job status.
Example:
To upload artifacts only when job fails:
job:
artifacts:
when: on_failure
allow_failure
BTW: you can tell Gitlab CI to continue to the next job after a job failure with allow_failure: true
source: Gitlab CI yaml Reference: allow_failure
job1:
stage: test
script:
- execute_script_that_will_fail
allow_failure: true
So combined it could look something like:
job1:
stage: test
script:
- execute_script_that_will_fail
allow_failure: true
artifacts:
when: always # or 'on_failure'
paths:
- resulting_artifacts
In my .travis.yml file, I have a test and deploy stage. I want to only execute the deploy stage if building a commit into master and not pull requests against master.
Current setup is like so:
stages:
- test
- deploy
matrix:
include:
-stage: test
...
-stage: deploy
I would like to add something like:
stages:
- test
- deploy
if: branch = master
matrix:
include:
-stage: test
...
- stage: deploy
...
I can't seem to get the latter to work using the syntax found in Travis documentation: https://docs.travis-ci.com/user/conditional-builds-stages-jobs/
If you use the built-in Travis deployment, you can simply do this:
deploy
--snip--
on:
branch: master
In the part I cut out (where it says --snip--), you would put your deployment provider.
More information here.
Hope this helps!
I'm creating a simple java project using Gradle which generates a test report (i.e. BDD Cucumber, JUnit, etc.). This project is deployed to Gitlab where the project is built as part of the Gitlab CI process.
My JUnit reports are generated in the folder build/reports/tests/test/ relative to the project path (as an index.html and some CSS files, etc.).
How do I configure my .gitlab-ci.yml to publish the content of build/reports/tests/test/ to the Gitlab Pages even after my test cases fail?
This is what I have in my .gitlab-ci.yml: (My repo can be found HERE)
Version 1: Doesn't publish anything to pages
image: java:8-jdk
stages:
- test
before_script:
- export GRADLE_USER_HOME=`pwd`/.gradle
test:
stage: test
script:
- mkdir public
- ./gradlew test
artifacts:
paths:
- build/reports/tests/test/
only:
- master
after_script:
- mv build/reports/tests/test/* public
Version 2: Doesn't execute the deploy stage since test has failed.
image: java:8-jdk
stages:
- test
- deploy
before_script:
- export GRADLE_USER_HOME=`pwd`/.gradle
test:
stage: test
script:
- ./gradlew test
artifacts:
paths:
- build/reports/tests/test/
pages:
stage: deploy
dependencies:
- test
script:
- mkdir public
- mv build/reports/tests/test/* public
artifacts:
paths:
- public
only:
- master
I solved the issue by adding the when: always at the end of my pages stage. It now executes the stage regardless of exit code from the dependent stage.
I have an application in springboot which uses gradle to build the code.
I have setup https://github.com/gabrie-allaigre/sonar-gitlab-plugin on SonarQube and have integrated gitlab CI
to analyse code on every push/commit. What I want to achieve is to break the push/commit if the analysis fails.
Below is my .gitlab-ci.yml
image: XXXXXX:oraclejdk:1.8.0_121
before_script:
- export GRADLE_USER_HOME=`pwd`/.gradle
sonarqube_master_job:
stage: test
only:
- master
- release2.0
script:
- ./gradlew assemble
- ./gradlew -x test sonarqube -Dsonar.host.url=http://sonarqube.XXX.XXX.XXX:9000/sonarqube -Dsonar.login=xxxxxxxxxxxxxxxxxxxx
sonarqube_preview_feature_job:
stage: test
only:
- /^feature\/*/
- development
script:
- git checkout $CI_COMMIT_REF_NAME
- git merge --no-commit --no-ff
- ./gradlew assemble
- ./gradlew -x test sonarqube -Dsonar.host.url=http://XXXX.XXXXX.com:9000/sonarqube -Dsonar.login=xxxxxxxxxxxxxxxxxxxxx -Dsonar.analysis.mode=preview -Dsonar.gitlab.commit_sha=$CI_COMMIT_REF -Dsonar.gitlab.ref_name=$CI_COMMIT_REF_NAME -Dsonar.gitlab.project_id=$CI_PROJECT_ID --stacktrace
How do I make sure the push fails if the analysis fails? Do I need to use webhooks. Is there a sample CI file?
#jibsonline, You can refer to my answer provided in the below link.
However the script answers only how to break the build on sonar analysis and display the results.
How to integrate Sonar Quality Gates with Gitlab-CI
Since gitlab triggers the build, once the changes were pushed, it is not advisable to set up an automated tool to revert the code changes on your behalf. Whenever a build fails, write script (dependencies) such that the code will not be deployed. Since the code is not deployed, your environment will not be effected. Also,set up an email configuration whenever build fails.