globocom / gitlab-lint

An open source gitlab linting utility

gitlab-lint API and collector

An open source gitlab linting utility

Frontend

https://github.com/globocom/gitlab-lint-react

How to install

Install dependencies

• Golang
• Docker
• pre-commit
• golangci-lint

Dev dependencies:

make setup

Create Gitlab access token

You should create a personal access token:

1. Sign in to GitLab.
2. In the top-right corner, select your avatar.
3. Select Edit profile.
4. In the left sidebar, select Access Tokens.
5. Choose a name and optional expiry date for the token.
6. Choose the read_api scope.
7. Select Create personal access token.
8. Save the personal access token somewhere safe. If you navigate away or refresh your page, and you did not save the token, you must create a new one.

Set the following environment variable with your token:

More info at Personal access tokens

export GITLAB_TOKEN="token"

Run it

make run-docker

Collecting the data

make collector

Managing rules

What are rules

Rules are how gitlab-lint knows what to look for on each processed project.

Take for an example the Empty Repository rule: its goal is to check if the current project houses an empty repository.

Creating new rules

Rules must implement the Ruler interface and they must have at least the following fields on their struct:

type Ruler interface {
	Run(client *gitlab.Client, p *gitlab.Project) bool
	GetSlug() string
	GetLevel() string
}

type MyAwesomeRule struct {
	Description string `json:"description"`
	ID          string `json:"ruleId"`
	Level       string `json:"level"`
	Name        string `json:"name"`
}

A good practice is to also have a NewMyAwesomeRule() function that returns an instatiaded rule's struct.

Notice that ID and GetSlug() should return a unique value to identify your rule.

Also, there's already a couple of pre-determined Levels on levels. We must use those instead of random strings.

Registering rules

After creating the rule itself, we must register it so it's considered when we parse the projects. In order to do it, we should just add it to the init() function on my_registry, just like so:

func init() {
	MyRegistry.AddRule(NewMyAwesomeRule())
	...
}

Then, you should be able to save (or recompile, if running a binary) and check your new rule being returned by running a GET to /api/v1/rules:

[
  {
    "description": "",
    "ruleId": "my-awesome-rule",
    "level": "error",
    "name": "My Awesome Rule"
  }
]

Contribute

Fork the repository and send your pull-requests.

gitlab-lint's Issues

Collector: Process rules in parallel

Today the collector get all projects list and process it for each rule.

Maybe, we can transform each rule in a worker and process it for all projects

Add HuskyCI rule

If there is gitlab-ci.yaml, it is desirable run security tests

https://github.com/globocom/huskyCI

Add rule about vendor folder

Migrating to Go Modules
https://blog.golang.org/migrating-to-go-modules

Add docs about how to create and add a new rule

Not found gets a http500 response

when querying for non-existing documents, we get 500 instead of 404.

Way to search a project for some text, namespace, path, id, etc

Automatically open an issue or MR for each gitlab repository that trigger some rule

Create API response metadata (pagination)

Maybe:

{
    "meta":{
        "limit":20,
        "next":"/api/v1/projects/?limit=20&offset=20",
        "offset":0,
        "previous":null,
        "total_count":1
    },
    "objects":[
        {
            "id": 123,
            "name": "My Gitlab project"
        }
    ]
}

Or follow the json-LD spec, there's even a go lib that could help us out. (by @luccamendonca)

Add swagger spec

See: https://github.com/swaggo/echo-swagger

Save all projects during the collection

When searching for projects, I would expect to see my project with every passing rules (no matching rules).
But only projects with any matching (failing) rule are persisted.

It would be nice to save every project, even if no rule was matched