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.
- 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.
- 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.
- GitLab CI CD Plugin Extension GitHub Action Super-Linter - as completed in live coding
- GitLab CI CD Plugin Extension GitHub Action Super-Linter - as productionized
- Example of Calling the Super-Linter GitLab Extension
- 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.
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