Add an automatic commenter for new tooling PRs. #173
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Deploying with
|
| Latest commit: |
c27b326
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://2dbe2d34.website-2v2.pages.dev |
| Branch Preview URL: | https://new-tooling-action.website-2v2.pages.dev |
4 tasks
This workflow will comment on PRs that add new tools / implementations
to the website. It will do so only on PR open (i.e. once), not whenever
the PR is modified.
The goal is to direct implementers (or users submitting on their behalf)
to review some resources that might be applicable to them.
We can of course grow or shrink this list as needed, if we wish to point
to additional resources.
Right now, the way it detects which PRs are tool additions is
by considering any PR which touches:
* the YAML files in the data directory
* the pages/implementations/main.md page
to be possible candidates.
Additional tweaks could be made to add or remove these triggers if the
commenter is too noisy, or not noisy enough.
Julian
force-pushed
the
new-tooling-action
branch
from
5b3aa52
to
b6440ad
Compare
benjagm
approved these changes
Oct 23, 2023
|
Ooh, good idea, yes, adding. |
gregsdennis
approved these changes
Oct 23, 2023
|
@Relequestual will let you take a look in case you didn't see this one yet before merging in case you have any other things you can think of to add. |
Julian
added a commit
that referenced
this pull request
Nov 6, 2023
This doesn't *seem* like it should matter -- in that this workflow was tested as-is on a different repository as part of building it, and ran successfully. Furthermore, the docs for the permissions property in GitHub (at https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs) say: You can use permissions either as a top-level key, to apply to all jobs in the workflow, or within specific jobs. When you add the permissions key within a specific job, all actions and run commands within that job that use the GITHUB_TOKEN gain the access rights you specify. so, top-level seems like it's supposed to work fine. And yet, in the "Set up job" step of #206, the permissions for PullRequest are shown as: PullRequest: read (https://github.com/json-schema-org/website/actions/runs/6762327321/job/18401399964?pr=206#step:1:18 though that link won't last forever). Let's see at least if this changes that... Refs: #173
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This workflow will comment on PRs that add new tools / implementations to the website. It will do so only on PR open (i.e. once), not whenever the PR is modified.
The goal is to direct implementers (or users submitting on their behalf) to review some resources that might be applicable to them.
We can of course grow or shrink this list as needed, if we wish to point to additional resources.
Right now, the way it detects which PRs are tool additions is by considering any PR which touches:
to be possible candidates.
Additional tweaks could be made to add or remove these triggers if the commenter is too noisy, or not noisy enough.
For PRs which touch these pages, this looks like:
PRs which do not meet the above detection are ignored.
Some further context on the immediate motivator of this is here.