Use project-relative path when calculating gitlab message fingerprint#11532
Use project-relative path when calculating gitlab message fingerprint#11532charliermarsh merged 1 commit intoastral-sh:mainfrom furgoose:gitlab-relative-project-fingerprint
Conversation
|
charliermarsh
left a comment
There was a problem hiding this comment.
This seems correct to me.
Then, we need to make sure to add this to |
|
Does that really qualify as a breaking change? I think it’s debatable. |
|
I might have jumped the gun but reading through it carefully it does seem like it should be fine (?) although I'm not exactly sure. Regardless, we should highlight this in the changelog. |
Summary
Concurrent GitLab runners clone projects into separate directories, e.g.
{builds_dir}/$RUNNER_TOKEN_KEY/$CONCURRENT_ID/$NAMESPACE/$PROJECT_NAME. Since the fingerprint uses the full path to the file, the fingerprints calculated by Ruff are different depending on which concurrent runner it executes on, so often an MR will appear to remove all existing issues and add them with new fingerprints.I've adjusted the fingerprint function to use the project relative path, which fixes this. Unfortunately this will have a breaking change for any current users of this output - the fingerprints will change and appear in GitLab as all linting messages having been fixed and then created.
Test Plan
cargo nextest runRunning
ruff check --output-format gitlabin a git repo, moving the repo and running again, verifying no diffs between the outputs