Integrate CI Lint into the Web IDE with immediate fix/commit workflow

Problem to solve

The CI configuration in gitlab-ci.yml is great, even greater with creating this file with the Web IDE and YAML syntax highlighting.

Whenever the configuration is wrong, e.g. YAML indent not correct, the triggered CI run fails.

It also hints again CI Lint at /orga/project/-/ci/lint

Screen_Shot_2019-10-14_at_16.27.02

Now there's two options:

  • Either you know about the error message, and can fix this inside the repository view or offline. The YAML error is very cryptic and hard to guess in most cases.
  • Or you use the CI Lint URL.

If I choose the second option, the CI Lint interface is opened empty. It expects to copy the content of the existing gitlab-ci.yml file.

Screen_Shot_2019-10-14_at_16.30.09

This step requires me to

  • open the project repository in a new tab
  • navigate into the gitlab-ci.yml content
  • copy the content into the first tab with the CI lint
  • try to fix the yaml file
  • copy the fixed content into the second tab and commit the change there

With knowing about the capabilities of the Web IDE, and putting the focus into just one tab, this should be made much more easy.

Intended users

  • System Administrators who setup the CI system initially, putting best practices
  • Developers/Development Team Leads who configure the CI jobs for their project

Further details

I'm providing trainings on GitLab, and my students are no YAML experts. Errors always occur, and specifically the first steps with the CI configuration sometimes prevent users to dive even deeper.

Users also keep writing the YAML file in vim, then add/commit/push and later seeing the error. With making this usable via the Web IDE, one can learn and push this awesome feature even further. Right now, the Web IDE is a bit hidden and evolves from releases and use cases, where I think this request is one of them.

Also, when I started with GitLab CI myself (and Travis with YAML before), I had a hard time remembering the syntax correctly. Which indent to use, how do the artifacts work and what exactly is a keyword on the top level, and what's free to use. Routine and doing it quite often helps with remembering, but the initial steps were hard and I wanted to eat my keyboard just because of YAML (and not the great GitLab CI). Don't get me wrong, YAML is the best format here instead of a DSL. GitHub Actions lately moved from their DSL to YAML again.

I did not contribute to GitLab yet, and I am not familiar with the code base. If you can point me to the code locations where to start, I may jump into working on an MR. I'm eager to learn and contribute to this great product :)

Proposal

  • Evaluate whether "CI Lint" can be made an extension to the Web IDE
  • Create a Web IDE "Action" to enable automated linting/highlighting e.g. via URL parameter
    • Evaluate read-only mode just for linting without saving
  • Migrate URLs for CI Lint
  • Optional tool tips when in lint mode in the Web IDE, e.g. with save/commit

Bonus

Next to linting in the Web IDE, also add auto-completion for .gitlab-ci.yml for keywords. I may open a different feature request for this though.

Edit: That's already possible with 12.3, sorry for the overlook.

Permissions and Security

Linting should be available read-only, as it is now. This makes the feature request a bit harder, since Web IDE access is likely read-write in permissions. It may need a read-only mode for the Web IDE here.

Once the user permissions allow to create a branch in the repository, show the store/commit buttons like usual in the Web IDE.

Documentation

Changes apply to

If you want to check whether the .gitlab-ci.yml of your project is valid, there is a Lint tool under the page /-/ci/lint of your project namespace. You can also find a “CI Lint” button to go to this page under CI/CD ➔ Pipelines and Pipelines ➔ Jobs in your project.

Testing

  • Check whether the CI Lint URL to the Web IDE and back work (browser cache)
  • Evaluate whether this is a wanted behaviour or if there are short-comings with e.g. read-only linting

What does success look like, and how can we measure that?

  • Success: When the clicks to validate/lint the CI configuration are much lower, and users gain faster success to working examples.
  • Acceptance: All users expect the CI Lint URL to actually point to an editable file with highlighting enabled.

What is the type of buyer?

Imho acceptance and tell others about a great product, so mainly adding this as core feature (and also CE) to make things easier to start with CI. When the first hurdle is taken, users can learn more about templates and don't need to care about the basics.

Edited by Michael Friedrich