Set up a minimal simple checkstyle quality gate

How to Use GitLab
1

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:

checkstyle:
  extends: .test-build-template
  stage: checkstyle
  artifacts:
    when: always
    paths:
      - "no_checkstyle_issues.txt"
    expire_in: 3 hrs
  script:
    - echo "Running checkstyle stage"
    - gradle checkstyleMain
    # no. of Checkstyle issues from previous commit
    - PREVIOUS_ISSUES=0
    - 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
    - CURRENT_ISSUES=0
    - 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?

Thanks

2

Hey there,

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).

3

@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.

4

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.

5

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:

GET /projects/:id/jobs/artifacts/:ref_name/raw/*artifact_path?job=name

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:

GET /projects/$CI_PROJECT_ID/jobs/artifacts/$CI_COMMIT_BRANCH/raw/no_checkstyle_issues.txt?job=checkstyle

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.