I have a CI/CD pipeline setup for my gitlab project. It runs multiple stages.
I want to setup a code quality analysis, from what I understood of the gitlab documentation, the config should be very straightforward : Gitlab - Code Quality.
So what I did, first, I added a .codeclimate.yml file in root project directory :
version: "2" # required to adjust maintainability checks
plugins:
gnu-complexity:
enabled: true
Then I added the required include and stage in my .gitlab-ci.yml:
stages:
- test
...
include:
- template: Code-Quality.gitlab-ci.yml
...
However, upon running the pipeline again, I still have no code quality tab and both the gitlab template and the code climate plugin don't seem to be executed at all.
What's strange is that I setup the gitlab SAST using the procedure and it worked well out of the box.
Did I do something wrong ? Thank you.
Related
I have GITLAB setup to pull repository from bitbucket.
I want pipeline to run automatically when there is pull request and when there are changes in files.
But it seems to not work.
This is the rule I have setup in pipeline:
rules:
- if: $CI_PIPELINE_SOURCE == "external_pull_request_event"
changes:
- Dockerfile
when: manual
Kindly help to debug
I want pipeline to run automatically
Then the first thing to change would be to remove the when:manual, which is used to require that a job doesn’t run unless a user starts it.
The combination you used (rules/if/changes/when:manual) was seen in the GitLab documentation at "Complex rules", but does not fit what you expressed in your question.
I have two sub projects in my repo.
The First one is .Net 5, The second is SharePoint solution. Both projects located in one branch.
How to configure pipeline only for one project?
I need to pass SAST test only for .Net 5 project. Now both projects are testing.
In my .gitlab-ci.yml:
include:
- template: Security/SAST.gitlab-ci.yml
stages:
- test
sast:
stage: test
tags:
- docker
First off - putting multiple projects into a single repo is a bad idea.
Second, the Gitlab SAST template is meant to be "simple to use", but it's very complex under the hood and utilizes a number of different SAST tools.
You do have some configuration options available via variables, but those are mostly specific to the language/files you are scanning. For some languages there are variables available that can limit which directories/paths are being scanned.
Since you haven't provided enough information to make a specific recommendation, you can look up the variables you need for your project(s) in the official docs here: https://docs.gitlab.com/ee/user/application_security/sast/#available-cicd-variables
If each Project, can have specific branch names, you can use
only--except or rules keywords to determine when jobs should run.
sast:
stage: test
tags:
- docker
only:
- /^sast-.*$/
It is for specific jobs, not sure about whole pipeline.
In my Gitlab project, I'm including multiple .yml files. One of them is remote and the other is a template provided by Gitlab for Code Quality.
The .yml configuration is written like so:
include:
- template: Code-Quality.gitlab-ci.yml
- remote: 'https://raw.githubusercontent.com/checkmarx-ltd/cx-flow/develop/templates/gitlab/v3/Checkmarx.gitlab-ci.yml'
Both of these templates are accessible. The first is located here, and the second Checkmarx one is here.
Both of these .yml configs define jobs that run in the test pipeline stage.
I'm having an issue where only the second include's jobs are running in the test stage, and the Gitlab Code Quality job is completely ignored. If I remove the external Checkmarx include, the Code Quality job runs just fine.
Normally I would just define separate stages, but since these .yml files do not belong to me, I cannot change the stage in which they run.
Is there a way to ensure the jobs all run in the test stage? If not, is there a way to override the stage a job from an external .yml runs in?
Oddly, there seems to be some sort of rules conflict between the two templates, possibly due to the variables that the checkmarx template sets. Even though the CI Lint shows that all 4 jobs should run successfully, I can reproduce your issue with the above code.
Given that it's likely a rules issue, I overrode the rules for running the code_quality job and was able to get both running within the same pipeline:
include:
- template: Code-Quality.gitlab-ci.yml
- remote: 'https://raw.githubusercontent.com/checkmarx-ltd/cx-flow/develop/templates/gitlab/v3/Checkmarx.gitlab-ci.yml'
code_quality:
rules:
- when: on_success
You can lint the above changes to confirm they're successful (though GitLab will warn you that without any workflow:rules, you'll wind up with duplicate pipelines inside MRs, which is true).
You can also see the pipeline running with both jobs here though checkmarx fails because I don't have a subscription to test it with:
I'm having some troubles understanding how to activate Secrets Detection in Gitlab CI/CD.
I created a new NodeJS Express from template and then i activated auto-devops from Settings > CI/CD and checked the checkbox Default to Auto Devops pipeline under the Auto Devops Menu. After that i opened the app.js file in the project folder and inserted a variable that looks like a key-value. Here's the piece of code where i inserted the line:
...
var app = express();
var key = "api-12321321321321321";
// view engine setup
app.set('views', path.join(__dirname, 'views'));
...
After committing the changes i expected the pipeline to fail because of the leak of the secret. Here's an images that shows that secret dection passed.
Can anyone tell me how to make so that the pipeline reports the error?
This behavior confused me as well when I first tried it out.
However, it seems that GitLab did this on purpose. Here is what the official documentation says:
So with a free or premium account, you can just use this reporter, but you won't see any results, unless you download the JSON report.
Also, there is NO mention that the job will fail. This is just our expectation.
However, there are reasons why this makes sense, especially for a paid version of GitLab. In an MR, you want to know if there are any vulnerabilities in your code. However, not all reports are accurate. So you may get what is known as a false positive. Or, the reported issue is very generic and your software is not affected.
However, if you are on a free/premium account, this feature is almost useless, as nobody will go to the job and manually inspect it.
The only workaround would be to override the secret_detection job, parse the gl-secret-detection-report.json, check if it passed or failed and decide to PASS or FAIL the JOB.
This should be easier with GitLab 13.12 (May 2021, Ultimate only):
Configuration tool for Secret Detection
Following in the footsteps of the GitLab SAST configuration tool we are adding support for Secret Detection on the Security Configuration page.
We believe that security is a team effort and this configuration experience makes it easier for non-CI experts to get started with GitLab Secret Detection.
The tool helps a user create a merge request to enable Secret Detection scanning while leveraging best configuration practices like using the GitLab-managed SAST.gitlab-ci.yml template.
The Configuration tool can create a new .gitlab-ci.yml file if one does not exist or update existing simple GitLab CI files, allowing the tool to be used with projects that already have GitLab CI setup.
See Documentation and Epic.
See GitLab 14.5 (November 2021, for all tiers)
Additional Secret Detection pattern support
We’ve updated the GitLab Secret Detection scanner to detect 47 new ‘well-identifiable’ secret patterns for widely used applications. This brings the GitLab Secret Detection detection up to over 90 detectable patterns.
If you are a SaaS application vendor and your app generates secret tokens with well-identifiable patterns, and you’d like GitLab to be able to detect them, please add your regex pattern and a few invalid sample tokens in a comment on this issue and we’ll get them added to GitLab Secret Detection.
See Documentation and Issue.
GitLab has a full post about setting this up in a pipeline: https://docs.gitlab.com/ee/user/application_security/secret_detection/
EDIT:
The given instructions are a bit unclear:
You need to add the include tag at "root-level" of your configuration.
Example
stages:
- build
- test
image: node:latest
build:
stage: build
script:
- echo "Building"
- npm install typescript
- yarn run build
test:
stage: test
script:
- echo "Testing"
include:
- template: Security/Secret-Detection.gitlab-ci.yml
The secret detection will run in the test stage:
Pipeline
Today, while trying to setup CodeQuality in my .gitlab-ci.yml (on gitlab-ee 11.10, gitlab-runner 11.10) I encountered the following issue:
First thing the GitLab documentation tells you is it is possible to set this with help of a DockerInDocker gitlab-runner and a single configuration line:
include:
- template: Code-Quality.gitlab-ci.yml
There is also disclaimer that this is supported in gitlab 11.11 or later, which is strange because as of April 23rd 2019, the latest version is 11.10. Not sure if this a typo or if they publish documentation before the releases are actually available.
I tried following this instructions but many things are unclear:
I realized that the include statement should be added after the stages definition for the syntax check to pass.
A code_quality job showed up and passed:
(source: cozyo.io)
However, later I learned from this answer that I need to create a .codeclimate.yml file and somehow add it .gitlab-ci.yml. That answer shares two links that can be used to understand how to work with CodeClimate but I'm haven't figured a way to add to gitlab-ci.yml. I found some example in this gitlab related page BUT this is not using the include statement described in the docs.
I'm unable to find the report of the code_quaity job that passed. In this answer someone pointed out that the report is only available for download on the merge request for gitlab-ee. However this is not practical since then devs would have to start spamming mock merge request just to see if they code suffered down grades.
The gitlab-ci.yml I use looks something like this:
image: docker:stable
variables:
ARTEFACT: my_app
VERSION: 0.1
DOCKER_HOST: tcp://docker:2375/
DOCKER_DRIVER: overlay2
services:
- docker:dind
before_script:
- docker info
stages:
- build
- test
- deploy
build:
stage: build
script:
- docker build -t $ARTEFACT:$VERSION-DEV .
test:
stage: test
script:
- docker run --rm --env MODE=DEV $ARTEFACT:$VERSION-DEV ./my_test.sh
include:
- template: Code-Quality.gitlab-ci.yml
Ideally, this should be a simple as figuring out how to use CodeClimate for python applications and then adding its configuration to the repo and referencing in gitlab-ci.yml correct? But how to make the reference. Is there any clear documentation available somewhere?
EDIT: I now know that jobs are independent and that I should modify the build stage in the .gitlab-ci.yml above to push the build image somewhere other jobs can pull from. Still this doesn't help to solve the CodeQuality problem I think.
First, yes, GitLab often has docs for features of the coming release before the official release. The docs often apply to pre-release versions which are often running on GitLab.com.
The docs could probably be clearer, so I encourage you to file an issue with specifics on how the docs could be improved or even submit a MR if you feel comfortable with that.
Do note that code quality is a paid feature so requires a Starter license for a self-managed install (or Bronze on GitLab.com).
The code quality process will store information based on the first run in a codeclimate.json file. This is merely reference for future runs and is not the code quality report itself. Upon subsequent runs, the code climate report will be viewable in the Merge Request which kicked off the pipeline.
In order for the code climate report to appear in the Merge Request, the following conditions must be met:
You've defined a job in your .gitlab-ci.yml which produces the Code Quality report artifact
The job must not be the first run. If the Code Quality report doesn’t have anything to compare to, no information will be displayed in the merge request area. That is the case when you add the Code Quality job in your .gitlab-ci.yml for the very first time. Consecutive merge requests will have something to compare to and the Code Quality report will be shown properly.
A code error must be present. There has to be a degradation/error in your code as this is what will be displayed in the merge request page. If the code is correct there will be nothing displayed.
The .json file must not be too large. There is an existing issue which prevents the code report from displaying when the related .json file is very large.