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.
#71
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
lint:ci
npm script to now output to console directly and exit with non-zero code on warnings.Validation performed
junhaoliao/yscope-log-viewer
.junhaoliao/yscope-log-viewer
.PR Link: https://github.com/junhaoliao/yscope-log-viewer/pull/10/files