I am migrating a project from Jenkins to GitLab. Using Jenkins we had a simple minimal quality gate for checkstyle, which I am trying to build in GitLab. This is my approach:
expire_in: 3 hrs
- echo "Running checkstyle stage"
- gradle checkstyleMain
# no. of Checkstyle issues from previous commit
- if [ -e no_checkstyle_issues.txt ]; then PREVIOUS_ISSUES=$(cat no_checkstyle_issues.txt); else PREVIOUS_ISSUES=99999; fi
- echo "No. of previous checkstyle issues = $PREVIOUS_ISSUES"
# no. of Checkstyle issues from current commit
- for file in $(find . -type f -name 'main.xml'); do CURRENT_ISSUES=$((CURRENT_ISSUES + $(grep -o '<error' $file | wc -l))); done
- echo "No. of current checkstyle issues = $CURRENT_ISSUES"
# if CURRENT_ISSUES > PREVIOUS_ISSUES, fail pipeline
- if [ $CURRENT_ISSUES -gt $PREVIOUS_ISSUES ]; then echo "Checkstyle issues increased. Failing pipeline!"; exit 1; fi
- mkdir -p artifacts/checkstyle
- echo $CURRENT_ISSUES > no_checkstyle_issues.txt
- exit 0
The problem I can in to lies in line
if [ -e no_checkstyle_issues.txt ]; then PREVIOUS_ISSUES=$(cat no_checkstyle_issues.txt); else PREVIOUS_ISSUES=99999; fi, which always returns
99999. So I guess the question comes down to, how can I share values between pipeline runs?
Furthermore, I a pretty sure I am not the first one doing this. What’s the “better” approach doing this?
Hard question. I’m not sure if it’s possible to pass though values between pipelines.
Between jobs in the same pipeline - yes - normally using an environment variables - have a look at the docs, but between different pipelines, not as far as I know.
Maybe, just maybe - you could somehow get it over the API, but this looks to me like a huge effort.
Other approaches - currently nothing comes to my mind. I believe most teams either do some git hooks and run it locally (no pushing unstyled code), or if they push it, they automatically style it, or just fail if the check is too low, dev needs to fix and push. But I’m not sure if they are always showing the diff in such manual use cases.
I’m not sure if there are any code quality tools that include this as well - in that case I’d imagine this being handled by 3rd party tool (keeping a history of quality or issues).
@paula.kokic thanks for your answer. To be honest, it is not quite satisfying. It’s kind of hard to believe, that this feature does not exist, as checkstyle is such an old tool.
Relying on developers is prone to errors. Automatically styling would assume just to style new added or edited lines in legacy projects.
Do you have any experience with Code Quality | GitLab or SonarQube? I still hope I’ll find the answer in there so I am investigating further.
I understand what you mean.
We use SonarQube. Works quite well with GitLab, but just FYI - developer license will give you better possibility for integration (e.g. MR decorations are nice). Even though it’s not super expensive (I believe around 120$ a year).
But, SonarQube is static code analysis tool, not really a style checker. Perhaps there are plugins for this, I’m not sure. My (very small) teams didn’t request this, I believe they have their own ways (Clang, IDE config shared across the team, etc) and it works for them.
Code Quality on GitLab I believe does the same, but I haven’t tried it out myself.
Btw, I just googled a bit.
Maybe you can really use GitLab API to download artifacts from previous pipeline. Official docs.
So, the call should be:
So, probably you could use
curl and download artifacts from previous successful pipeline - now this might be tricky, as GitLab might see the previous one as failed if style checker failed (and it wasn’t allowed to fail).
But technically, you should have all the data. Using GitLab predefined variables you should have sth like this:
Perhaps you can give it a shot.
P.S. There is a GitLab CLI as well - basically a wrapper around API I believe. Maybe this would be even more elegant solution - have a look at downloading artifacts option.