ataylorme / eslint-annotate-action

A GitHub action that takes ESLint results from a JSON file and adds them as annotated pull request comments
MIT License
88 stars 32 forks source link

Annotations show up as part of a different workflow #35

Closed oxc closed 2 months ago

oxc commented 2 years ago

I have multiple workflows that get triggered on pull_request. One of them is called "Run tests for pull request" and has a job called "Run linter" that runs the eslint-annotate-action.

However, the annotations often show up as child of a completely unrelated workflow. It seems undeterministic under which workflow it shows up.

In the following example, the annotation results wrongly show up as part of the "Code coverage" workflow: image

Here is an excerpt from the workflow that runs the action:

name: Run tests for pull request

on:
  pull_request:
    branches: [main]

jobs:
  lint:
    name: Run linter
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repo
        uses: actions/checkout@v2

      - name: Install Dependencies
        run: npm run install:all

      - name: Generate lint report
        run: npm run lint:report
        continue-on-error: true

      - name: Annotate Code Linting Results
        uses: ataylorme/eslint-annotate-action@1.2.0
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}
          report-json: eslint_combined_report.json
ataylorme commented 2 years ago

The Action creates a new status check and the Action doesn't have control where that is displayed in the UI as far as I know. Do you have any suggestions on what the Action can do differently that would help resolve your issue?

oxc commented 2 years ago

Thanks for your reply. You're right, this seems to be an issue in Github that many people are complaining about: https://github.community/t/github-actions-status-checks-created-on-incorrect-check-suite-id/16685

According to this thread, there does not seem to be a solution at the moment (using a Github App instead of an Action seems to be "the way").

Related threads:

Feel free to close this, or keep it open for whenever this might be possible to implement.

noamgolani commented 1 year ago

Can't this be solved with setting an external_id when creating the check?

https://docs.github.com/en/rest/checks/runs#create-a-check-run:~:text=app%20is%20used.-,external_idstring,A%20reference%20for%20the%20run%20on%20the%20integrator%27s%20system.,-statusstring

ataylorme commented 1 year ago

@noamgolani can you elaborate on how external_id would tie the status check to a job in the UI?

szepeviktor commented 1 year ago

The above linked docs say.

external_id string A reference for the run on the integrator's system.

That must be a reference to CI-s running outside GitHub Actions.

ataylorme commented 2 months ago

Closing this as I don't think there is anything I can do.

Also dropping a note that 3.0.0 has been released. Please update any references to the v3 branch instead of v3-beta. Make sure to read the Changeling as there are breaking changes (GH_TOKEN input has changed)