GitLab Continuous Integration (CI) service is a part of GitLab that builds and tests the software whenever the developer pushes code to an application similar to GitHub actions.
This is so to keep and enforce developers to keep the coding standard clean and readable as possible.
I this post will look on how to integrate GitHub super lint on both platforms GitLab and GitHub
The Super Linter is a source code repository that is packaged into a Docker container and called by GitHub Actions. This allows for any repository on GitHub.com to call the Super Linter and start utilizing its benefits.
How it works
This action will run on your repository, every time you open a pull request, it will start linting the code base and return via the Status API. It will let you know if any of your code changes passed successfully, or if any errors were detected, and highlit the files that contain the errors and the issue and what they are.
This allows the developer to go back to their branch, fix any issues, and create a new push to the open pull request. At that point, the Super Linter will run again and validate the updated code and repeat the process.
You can configure your branch protection rules to make sure all code must pass before being able to merge as an additional measure.
Before you start make sure you head over super lint repository and read the docs to get familiar with the variables and how to.
setting up super lint in your GitHub action
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
---
###########################
###########################
## Linter GitHub Actions ##
###########################
###########################
name: Lint Code Base
#
# Documentation:
# https://help.github.com/en/articles/workflow-syntax-for-github-actions
#
#############################
# Start the job on all push #
#############################
on:
push:
branches:
- master
pull_request:
branches:
- master
###############
# Set the Job #
###############
jobs:
lint:
# Name the Job
name: Lint Code
# Set the agent to run on
runs-on: ubuntu-latest
##################
# Load all steps #
##################
steps:
##########################
# Checkout the code base #
##########################
- name: Checkout Code
uses: actions/checkout@v2
################################
# Run Linter against code base #
################################
- name: Lint Code Base
uses: github/super-linter@v3
env:
#set this rule if your using eslint rules like abnb ES js
JAVASCRIPT_ES_CONFIG_FILE: .eslintrc.js
VALIDATE_ALL_CODEBASE: false
DEFAULT_BRANCH: master
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
you will get an error if you lint both javascript standards were ES end with a semicolon and standard js doesn’t so make sure you define the rules in your env variable.
How to set supper lint in GitLab CI
1
2
3
4
|
superlinter:
image: github/super-linter:latest
script: [ "true" ]
variables: { RUN_LOCAL: "true", DEFAULT_WORKSPACE: $CI_BUILDS_DIR }
|
This was more complicated to get to run since we have to npm install the modules that our eslint rule will use the validate our js so someone helped me tweak this to get it to work
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
superlinter:
image:
name: github/super-linter:latest
entrypoint: [""]
script:
- |
npm install
/action/lib/linter.sh
variables:
RUN_LOCAL: "true"
DEFAULT_WORKSPACE: $CI_BUILDS_DIR
ANSIBLE_DIRECTORY: $CI_PROJECT_PATH
LINTER_RULES_PATH: $CI_PROJECT_PATH/.github/linters #make sure your eslint is lacated here
JAVASCRIPT_ES_CONFIG_FILE: .eslintrc.js
VALIDATE_JAVASCRIPT_STANDARD: "false"
|
you will get an error if you lint both javascript standards were ES end with a semicolon and standard js doesn’t so make sure you define the rules in your env variable. so you will have to disable the standard js.
