fix: use correct linter

[fallion]

Important

Update Docker image sources for Commitsar and Release Notary in GitHub Actions workflows.

• Workflows:
  • In linters.yml, change Commitsar Docker image from outillage/commitsar to aevea/commitsar.
  • In release.yml, change Release Notary Docker image from outillage/release-notary to aevea/release-notary.

^{This description was created by for 784f674. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 784f674 in 1 minute and 22 seconds. Click for details.

• Reviewed 25 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .github/workflows/linters.yml:12

• Draft comment:
  Using docker://aevea/commitsar is valid, but consider pinning a specific version tag to ensure reproducibility and avoid unexpected changes.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The PR change is simply updating the docker image source from one organization to another (outillage to aevea). The comment is suggesting to add version pinning, but this is not related to the actual change - the original code also didn't have version pinning. This is a general best practice suggestion, not a comment about the specific change made. According to the rules, comments should be about code changes required, not general suggestions about unchanged patterns. The versioning strategy wasn't changed in this PR - only the image source was changed. Could the change in docker image source be a good opportunity to also add version pinning? Perhaps the comment is trying to prevent issues that could arise from the new image source not being pinned. The migration to a new image might be a natural time to improve the configuration. While it might be a good opportunity, the comment is not about the change itself - it's about a pre-existing pattern that wasn't modified. The rules explicitly state to only comment on changes made, not on unchanged code patterns. If version pinning was important, it should have been addressed when the original code was written, not now when only the image source is being updated. This comment should be deleted because it's not about the actual change made in the PR. The PR only changes the docker image source from one organization to another, maintaining the same versioning pattern (no pinning) that was already in place. This is a general best practice suggestion about unchanged behavior, not a comment about the specific modification.

2. .github/workflows/release.yml:15

• Draft comment:
  Using docker://aevea/release-notary is correct; however, consider specifying an explicit version tag to prevent potential issues with future image updates.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% The comment is about a change that was made (the docker image name). It's suggesting a code quality improvement - pinning to a specific version tag. However, I need to consider the rules: the comment says "consider specifying" which is somewhat suggestive rather than directive. The rules say not to make speculative comments and to only comment if there's clearly a code change required. This is more of a best practice suggestion rather than identifying a bug or clear issue. The PR author intentionally changed the image name but didn't add a version tag, so they may have reasons for using latest. The comment doesn't identify a definite problem, just a potential future issue. This could be considered a valid code quality suggestion since pinning versions is a well-established best practice in CI/CD. The comment is actionable and clear. It's not speculative about "if X then Y" - it's pointing out a real risk of using untagged Docker images. While version pinning is a best practice, the comment uses soft language ("consider") and doesn't identify a definite issue with the current code. The rules emphasize only commenting when there's "clearly a code change required" and to avoid comments that aren't about definite issues. This is more of a suggestion for improvement rather than a clear problem that needs fixing. This comment should be deleted. While it suggests a valid best practice, it doesn't identify a clear code issue that requires a change. The soft language ("consider") and the speculative nature ("potential issues with future image updates") make it more of an optional suggestion rather than a required fix.

Workflow ID: wflow_hjaBxI17Ahu5e8sW

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}