chore: Update GitHub Actions workflow for coverage badge handling

[dev-jodee]

• Modify coverage.yml to trigger on pull requests to main.
• Adjust badge update logic to commit and push to the PR branch for pull requests, while ensuring no action is taken for merges to main.

---

Important

Update GitHub Actions workflow to handle coverage badge updates for pull requests and merges differently.

• Workflow Trigger:
  • Modify .github/workflows/coverage.yml to trigger on pull requests to main instead of only on main branch.
• Badge Update Logic:
  • Adjust logic to commit and push badge updates to the PR branch for pull requests.
  • Ensure no badge update action is taken for merges to main.

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

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 549cd24 in 1 minute and 34 seconds. Click for details.

• Reviewed 56 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 5 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/coverage.yml:16

• Draft comment:
  Consider guarding against undefined workflow_run in the job 'if' condition. Using 'github.event.workflow_run.conclusion' in a pull_request event might lead to unexpected behavior. Consider explicitly checking if the property exists.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

2. .github/workflows/coverage.yml:24

• Draft comment:
  For clarity and future maintainability, consider using the ternary operator instead of the '&& ||' pattern. For example: ref: ${{ github.event_name == 'pull_request' ? github.head_ref : 'main' }}.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The suggestion is technically correct - a ternary operator would be more explicit and slightly more readable. However, the && || pattern is a common idiom in GitHub Actions YAML files. The change is minor and mostly stylistic. The current code is not wrong or confusing enough to warrant a required change. The && || pattern could potentially cause unexpected behavior in some edge cases where head_ref is falsy. Also, some developers might actually prefer the current syntax as it's more concise. While the ternary operator is slightly more explicit, the current pattern is well-established and the edge cases aren't relevant here since head_ref will always be a string. This is a style suggestion that doesn't meaningfully impact code quality or correctness. While not wrong, it's not important enough to warrant a comment.

3. .github/workflows/coverage.yml:65

• Draft comment:
  Consider defining an environment variable for github.event_name to improve readability in shell conditions. Direct interpolation in the shell script may be less clear.
• 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 current usage is actually quite clear and standard in GitHub Actions. The comment suggests a refactor that wouldn't necessarily improve readability - the current form is idiomatic and immediately recognizable to anyone familiar with GitHub Actions. The condition is used only once in the shell script, so extracting it to a variable wouldn't reduce duplication. Perhaps extracting to a variable would make the code more consistent with other shell script best practices and make it easier to modify the condition later. The current form is more idiomatic for GitHub Actions workflows and the condition is simple and used only once. The suggested change would add complexity without clear benefit. Delete this comment as it suggests a refactor that wouldn't meaningfully improve code quality and goes against GitHub Actions idioms.

4. .github/workflows/coverage.yml:32

• Draft comment:
  Adding 'set -e' at the top of the run script can help the job fail fast on errors. This is a best practice in shell scripts.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

5. .github/workflows/coverage.yml:74

• Draft comment:
  A newline at the end of the file is recommended for POSIX compliance. Please add one.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50% None

Workflow ID: wflow_V6TsA8fuPnFA93EH

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

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to ae29230 in 1 minute and 16 seconds. Click for details.

• Reviewed 49 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 4 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/coverage.yml:28

• Draft comment:
  Consider adding 'set -euo pipefail' at the beginning of the run script for more robust error handling.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

2. .github/workflows/coverage.yml:60

• Draft comment:
  For clarity and to avoid duplication, assign the head branch to a variable once and reuse it.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

3. .github/workflows/coverage.yml:67

• Draft comment:
  Ensure that the target branch exists on the remote (origin) to prevent push failures when updating the badge on PR branches.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

4. .github/workflows/coverage.yml:73

• Draft comment:
  Add a newline at the end of the file to adhere to best practices.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While having a newline at end of file is a common best practice, this is a very minor issue that would likely be caught by standard IDE settings or git configurations. It doesn't affect functionality and is more of a style preference. The comment, while technically correct, doesn't address any meaningful code quality or functionality concerns. The missing newline could potentially cause issues with some tools or shell scripts that expect files to end with newlines. Some version control systems also flag this. While true, this is still a very minor issue that would be better handled by IDE settings or git configurations rather than PR comments. The benefit of fixing this is minimal compared to the noise it adds to the review. This comment should be removed as it addresses a very minor style issue that doesn't meaningfully impact code quality or functionality.

Workflow ID: wflow_8VObHx2kG3UgQv6t

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

[amilz]

Makes sense to me. Let's keep an eye on how it performs with a few merges.