new-log-viewer: Treat ESLint warnings as errors; Remove ataylorme/eslint-annotate-action and instead rely on setup-node's problem matcher to annotate ESLint errors in PRs.

[junhaoliao]

References

new-log-viewer series: #45 #46 #48 #51 #52 #53 #54 #55 #56 #59 #60 #61 #62 #63 #66 #67 #68 #69 #70

#61 added lint workflow for the new-log-viewer; #68 updates the lint workflow trigger condition to include PR "synchronize" - pushes to the PR source branch.

After the lint workflow was added, it was found that the ESLint analysis action "ataylorme/eslint-annotate-action@v3" uses permissions including but not limited to "checks: write" [1][2], which is beyond the maximum access for pull requests from public forked repositories (all "read" only)[3], and lint errors are not getting reported directly in PR changed files, causing confusions and void the efforts for lint check automations.

One viable solution is to create a Personal Access Token (PAT), store it as a repository secret and use it instead of secrets.GITHUB_TOKEN in the workflow. At the moment, there are two types of PAT that GitHub offers: "classic" and "fine-grained" with the later still in "beta" phase. The "classic" type does not offer options to configure in which repository the accesses can be granted; while the "fine-grained" type does not seem to offer "checks" permission grants. As a result, there is no clean way to obtain a token dedicated for linting in this specific repo.

On the other hand, we can fallback to having the lint results output to the console and rely on "problem matchers" to annotate any potential issues. In fact, the actions/setup-node@v4 action used in the workflow provides an ESLint problem matcher already.

[1] ataylorme/eslint-annotate-action#42
[2] https://github.com/ataylorme/eslint-annotate-action/blob/3470c7a7e9a4e5ae2d7276a547691f31015ed721/src/createStatusCheck.ts
[3] https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#:~:text=Maximum%20access%20for%0Apull%20requests%20from%0Apublic%20forked%20repositories
[4] https://github.com/actions/setup-node/blob/main/.github/eslint-stylish.json

Description

1. Replace custom action with problem matcher for ESLint issue display in new-log-viewer lint workflow.
2. Change lint:ci npm script to now output to console directly and exit with non-zero code on warnings.

Validation performed

1. With another GitHub account, created a fork from junhaoliao/yscope-log-viewer.
2. Made lint violations including errors and warnings on the forked repo's branch.
3. Created a PR from the forked repo to junhaoliao/yscope-log-viewer.
4. (Junhao approved the PR workflow run since the new account is a first-time contributor to the repo.) The workflow ran and the lint warnings and errors got marked in the PR's "Files changed" tab.

PR Link: https://github.com/junhaoliao/yscope-log-viewer/pull/10/files

[davemarco]

I tested this and it looked okay on my test branch. Honestly, I found the "ataylorme/eslint-annotate-action@v3" would sometimes load the wrong file after clicking on the annotations, so I am happy to get rid of...

[kirkrodrigues]

For the PR title, how about:

new-log-viewer: Treat ESLint warnings as errors; Remove ataylorme/eslint-annotate-action and instead rely on setup-node's problem matcher to annotate ESLint errors in PRs.