In the most recent Mission Impossible Live Coding event, Jefferson and I convert the GitHub Action Super-Linter to run in GitLab CI. This is a summary of lessons learned and pointers to the results.

So Jefferson and I worked through this approach. Before the session I played with some ideas and approaches, but ultimately we ended up with a new approach.

Lessons Learned:

GitLab has linting as a part of it’s built-in Code Quality scanning:
- But it can be a challenge to figure out that this is where GitLab CI does linting - you have to dig into the website of the underlying software “Code Climate” to figure out that this is being done and for what languages.
- GitLab’s built-in support is configurable, including adding your own Code Quality scanning jobs with additional products.
Super-Linter has a lot of language coverage.
Super-Linter is implemented in a container - this means implementation on GitLab CI should be even easier - especially if the image built for it is publicly available. If the image was not publicly available, we would have built the docker file on GitLab as a prerequiste to using it in GitLab CI.
Super-Linter is driven by a lot of variables - very compatible with GitLab CI.
Super-Linter has a special parameter, RUN_LOCAL, that overrides a bunch of expected GitHub Actions input parameters - so we don’t need to emulate or map those expected parameters. Perhaps many GitHub Actions can be repurposed easily using this parameter.
Super-Linter only outputs results to the log - not as an artifact file. Hopefully as it matures it will be able to emit test results. If it could emit JUNIT.xml we could have loaded the results into GitLab’s test results visualization panels. If we could transform the results into GitLab Code Quality result format, results could be even more deeply integrated inline into Merge Requests.

Techniques Demonstrated:

Examing the source code and documentation for clues on how to implement Super-Linter outside of GitHub.]
Iteration - Let GitLab CI “give it a shot” while we research other things.
Moving variable declarations around to ensure they are encountered early enough (a final break through by Jefferson was to move a key variable declaration from the script into GitLab’s variables: block)
Make Into a Plug-in Extension by:
- Reimplementing the live code in a way that enables it to be simply included in other CI.
- Provide an example of calling the plug-in.
- Demonstrate how to version peg the plug-in using GitLab’s include:ref: to point to a specific git tag of the plugin.

The Code

References

GitLab Built-in Code Quality Scanning
Which uses CodeClimate, here are the Supported Scanning Engines, Including Linting
Implementing a Custom Code Quality Tool in GitLab

Mission Impossible Live Coding

The past recordings, including the above are at: https://www.youtube.com/channel/UCcL7kaon80MiwuGcNI7A1Dg

We are live coding every two weeks on Friday at 2pm ET - the next one will be on July 3rd.

You can add it to your calendar with this .ICS file.

The live stream will is at: https://www.twitch.tv/missionimpossiblecode and https://www.youtube.com/channel/UCcL7kaon80MiwuGcNI7A1Dg.

We will be using GitLab issues to queue up questions and enable you to submit code snippets for consideration. Please use this GitLab project for that purpose: https://gitlab.com/missionimpossiblecode/live/-/issues

Live Coding Conversion of GitHub Action Super-Linter to GitLab CI