manu_faktur, 9 months ago

@anderseknert You can "Create a new thread in the merge request diff" via the API (https://docs.gitlab.com/ee/api/discussions.html#create-a-new-thread-in-the-merge-request-diff). Is that what you're going for?

anderseknert, 9 months ago

@manu_faktur Thanks! I'm not sure what a "thread" is? Is that like a comment? I suppose it could be done that way, but the nice thing about annotations is that they aren't from a user, but the tool in the build step emitting them. That also means people won't need to be pinged, as they are when someone comments.

manu_faktur, 9 months ago

@anderseknert Exactly, see sample screenshot. If you post these using the API, they will come from whoever authenticates that API request, could very well be a bot user. https://danger.systems/ruby/ works like that too, for example.

I must admit I have no idea how the Github variant works, sounds like it's a "first class citizen" to the process instead of "re-using" comments?

anderseknert, 9 months ago

@manu_faktur Thanks! That's useful, and perhaps for another time. But yeah, something more lightweight would indeed be what I'm looking for. I think the code quality stuff seems to come closest of what I've seen so far. I'll keep you posted on my progress :)

thiagocsf, 9 months ago

@anderseknert @manu_faktur I understand what you’re trying to do now: use the code quality report as a way to annotate the diff view of the MR. I’m not sure it’s much easier to do the report integration (https://docs.gitlab.com/ee/ci/testing/code_quality.html#implement-a-custom-tool) than using the discussion API. For a boring solution, I’d try to convert the existing output into discussion GitLab API calls. FWIW, With the code quality integration you’d still see results in the MR widget without Ultimate. Feel free to tag me in GitLab if you want any help. I’m thiagocsf.

anderseknert, 9 months ago

@thiagocsf @manu_faktur Thanks! That's much appreciated. I never got the code quality reports to work reliably though, and I'm not sure what I did wrong. Doesn't matter much though as it seemed like the code quality report was purely informational and didn't actually fail the job, which I'd want. Could be I come back to this later but for now I've just settled on running the linter as a "normal" job.

anderseknert, 9 months ago

Annotating GitHub PRs, and printing nice looking job summaries, will be possible starting from the next version of Regal 😃

https://github.com/StyraInc/regal/pull/273

anderseknert, 9 months ago

Looks like this is what one should be doing for similar effect in GitLab, although the annotations seem to be available only when using the "Ultimate" edition 💸 https://docs.gitlab.com/ee/ci/testing/code_quality.html#implement-a-custom-tool

akosma, 9 months ago

@anderseknert pinging @dnsmichi in this thread

dnsmichi, 9 months ago

@akosma @anderseknert Thanks for the tag.

Code quality reports can be integrated as MR widget, that works for all tiers. https://docs.gitlab.com/ee/ci/testing/code_quality.html#features-per-tier

Junit test reports could be another way for summaries. https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html

To reach more GitLab users, I'd suggest asking on the forum or Discord :) https://about.gitlab.com/community/

anderseknert, 9 months ago

@dnsmichi @akosma thanks! I’ve gotten some excellent help from your colleagues here, but if I need more later I’ll check out the discord.

Do you know if there is any open feature request I can track for creating ad-hoc annotations from CI scripts similar to how GitHub allows?

dnsmichi, 9 months ago

@anderseknert @akosma I'm not sure I understand the purpose of https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions - I would just use the echo command, and pre-defined CI/CD variables from https://docs.gitlab.com/ee/ci/variables/predefined_variables.html

If that does not solve the question, feel free to open a feature proposal :) https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Proposal%20-%20lean

anderseknert, 9 months ago

@dnsmichi @akosma just echoing isn’t going to have any output visible in the PR at the locations I want. That’s the purpose of workflow commands.

dnsmichi, 9 months ago

@anderseknert @akosma I'm not following what "visible in the PR at the locations" means. Please create an issue and tag me there to continue the discussion :)

thiagocsf, 9 months ago

@anderseknert if your project is open-source, you can apply for a free Ultimate licence. Not only you get code quality, but also all the vulnerability management features and other goodies. https://about.gitlab.com/solutions/open-source/

anderseknert, 9 months ago

@thiagocsf Thanks Thiago! I'm working on a linter, and the linter itself is hosted on GitHub ( https://github.com/StyraInc/regal ). I did however set up an account and a project to see what options GitLab provided for me in order to provide the best possible experience for people using the linter in GitLab CI.

I played around with the "code quality" stuff yesterday, but I'm not sure it was the right tool for the job, as I want linter violations to fail the build and not just be reported in the UI.

anderseknert, 9 months ago

@thiagocsf But ideally, my linter job would be able to fail the build and annotate the PR with the violations at the right location. From what I've seen, GitLab does not provide any light-weight methods for pushing ad-hoc PR annotations from CI pipelines. Not a huge deal, but I'd love to see it :)

thiagocsf, 9 months ago

@anderseknert thanks! That’s all possible. It’s just a matter of how effort. Our options are definitely a bit more effort than simply echoing a formatted string to the build log. Come to think, I wonder if there’s a way to create a parser for the logs in the GitLab build that looks for these strings and converts them into api calls. 💡