Use project-relative path when calculating gitlab message fingerprint

[furgoose]

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 run

Running ruff check --output-format gitlab in a git repo, moving the repo and running again, verifying no diffs between the outputs

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[charliermarsh]

This seems correct to me.

[dhruvmanila]

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.

Then, we need to make sure to add this to BREAKING_CHANGES.md in the next release similar to https://github.com/astral-sh/ruff/blob/main/BREAKING_CHANGES.md#improved-gitlab-fingerprints-7203

[charliermarsh]

Does that really qualify as a breaking change? I think it’s debatable.

[dhruvmanila]

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.