Is there some integration available in GitLab for various linters/formatting tools?
Of course, you can always manually program a pipeline step that'd get the tested diffs, run the tool on them and fail if it encounters any issues, but that's suboptimal from usability perspective (especially for huge diffs/logs).
I.e. some review tools support posting the lint/codestyle check results inline (see https://github.com/traveloka/hubormaster as an example of what I'd ideally want to achieve).
Is anything like this possible in the current GitLab? Is there a tracking issue for this?
I believe you can use Danger for something like this. You'd need a job which does the linting / formatting, and then have a Dangerfile (with some Ruby, if you use that option), which formats the message to include the line number.
You can check the reference for their GitLab integration and options available.
Short example:
.gitlab-ci.yml:
danger:
stage: lint
image: <docker image with Danger>
script:
- danger --version
- danger --dangerfile=Dangerfile --verbose
tags:
- docker
Dangerfile:
warn("Please add something", file: "README.md", line: 1)
Related
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:.
The majority of .gitlab-ci.yml files which I have seen follow the pattern
build-code:
stage: build
script:
do-somthing.
However, I see some documentation that has steps defined like this
build:default:
stage: build
script:
do-something.
I do not understand why some steps are written with [a-z]+:[a-z]+: pattern as demonstrated by this link for "needs"
Can someone explain which concept is being used when we write steps in this pattern "linux:build:" ?
You can choose the pattern build:linux: if you have other types of builds in your pipeline, like build:mac: and build:netbsd.
But if you prefer you can write build-linux:, ... instead.
It is just a question of style. No other means. And of course, it's not related to builds. In general it's used when you want to visually group similar jobs: group:action1, ...
I'm absolutely new to all this ci/cd thing and its documentation is too extensive. So i'd like to apologize in advance if there is too easy question.
I have gitlab repo with many configs for different services i.e:
project_folder
--global_conf.json
--service1
----config_folder
------....
--service2
----config_folder
------....
--service3
----config_folder
------....
I'd like to know what should I do (just general plan and some key words to search documentation more precisely already would be fine) to send to hosts [host1:port, host2:port, host3:port] different strings with commands "check {service_name} for changes" or "check {global_config} for changes" e.t.c, depending on the file that was committed.
I already have my service on each host that could perform different operations for different task's strings, so I need just send them that task.
You'll propably end up using "only: changes" as explained here.
Something like this should fit:
stages:
- trigger
service1:
stage: trigger
script:
- curl http://host1:port1
only:
changes:
- service1/*
service2:
stage: trigger
script:
- curl http://host2:port2
only:
changes:
- service2/*
We have a copy of to-be-continuous at Orange, which is currently used like this:
include:
# Python template
- project: "to-be-continuous/python"
ref: "1.2.2"
file: "/templates/gitlab-ci-python.yml"
However I have no idea how the sync works with the Orange repo, and I'm thinking it's better to make all projects directly include the gitlab.com link for faster access to new functionnalities, what do you think, do you expect any issues, security or operational wise?
include:
# Python template
- remote: 'https://gitlab.com/to-be-continuous/python/-/raw/1.2.2/templates/gitlab-ci-python.yml'
To-be-continuous at Orange are syncronised every night with gitlab.com. So you don't miss any newer functionalities. My suggestion is to use 1st include, because our internal repo have more customisation for our needs like devops-store variant, ODE..
Prefer use first include for all current cases.
You have to use second include for example to validate a new functionality not yet merged.
The include/remote may work but requires that your GitLab server has a direct access to the referenced link (gitlab.com in your case).
/!\ the include/remote syntax doesn't not support double include: when you're trying to include a template that itself includes a (local) template.
I know that you can reuse blocks of code in a before script using yaml anchors:
.something_before: &something_before
- echo 'something before'
before_script:
- *something_before
- echo "Another script step"
but this doesn't seem to work when the .something_before is declared in a shared .yml file via the include:file. It also does not seem that extends works for before_script. Does anyone know a way of reusing some steps in a before_script from a shared .yml file?
EDIT: My use case is that I have 2 gitlab projects with almost identical before_script steps. I don't want to have to change both projects whenever there's a change, so I have a third, separate Gitlab project that has a .yml template that I am including via include:file in both projects. I want to put all the common code in that shared template, and just have like two lines before_script for the git project that has the two extra steps.
Yaml anchors don't work with included files. You need to use the extends keyword. But what you want to achieve won't work with before_script as code in your template will be overwritten in the job which uses the template if there is a before_script as well.
Do you really need a before_script in your specific job or can you achieve the same with a normal script? If yes you can do something like this:
Template File:
.something_before:
before_script:
- echo 'something before'
- echo 'something more before'
Project Pipeline:
include:
- project: 'my-group/my-project'
file: '/something_before.yml'
stages:
- something
something:
stage: something
extends: .something_before
script:
- echo 'additional stuff to do'
And your before_script section will be merged into the something job and executed before the script part.
See if GitLab 13.6 (November 2020) does make it easier:
Include multiple CI/CD configuration files as a list
Previously, when adding multiple files to your CI/CD configuration using the include:file syntax, you had to specify the project and ref for each file. In this release, you now have the ability to specify the project, ref, and provide a list of files all at once. This prevents you from having to repeat yourself and makes your pipeline configuration less verbose.
See Documentation) and Issue.
And even, with GitLab 14.9 (March 2022):
Include the same CI/CD template multiple times
Previously, trying to have standard CI/CD templates that you reuse in many places was complicated because each template could only be included in a pipeline once.
We dropped this limitation in this release, so you can include the same configuration file as many times as you like.
This makes your CI/CD configuration more flexible as you can define identical includes in multiple nested configurations, and rest assured that there will be no conflicts or duplication.
See Documentation and Issue.
You can use extends without any problem, but you will need to overwrite the entire before_script block.
If you want to change just a piece of your before_script, use a shell script to do it
Set the if condition inside of your template
before_script
- |
if [ condition ]
then
commands here
fi
AFTER EDIT: You can use variables to achieve it
Project 1: VAR = command 1
Project 2: VAR = command 2
You can set the content of env var on the gitlab-ci.yml file or on the CI/CD settings in each project!