Conversation
| corepack prepare yarn@3.8.3 --activate | ||
| yarn set version 3.8.3 |
There was a problem hiding this comment.
Is there a reason for pinning an exact yarn version here, rather than letting corepack handle it in the usual way (with simply corepack enable)?
| "@types/xml2js": "^0.4.11", | ||
| "jest": "^29.4.3", | ||
| "open-cli": "^7.1.0", | ||
| "pkg-pr-new": "^0.0.50", |
There was a problem hiding this comment.
I dont think this needs to be here. The workflow is using yarn dlx which will download a temporary version of the package, and I think it will ignore this version entirely. So this being here serves no purpose?
Julusian
left a comment
There was a problem hiding this comment.
I can see the value of this, and it isnt very invasive, so I am open to including this.
I have not heard of this tool before though, so am a bit cautious of it..
So on that note, I think it would be good to limit the permissions of the workflow by adding:
permissions:
contents: read
at the root level, just so that I don't have to worry about about what the package might be doing
|
|
||
| steps: | ||
| - name: Checkout code | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
In the same way of limiting permissions of this, I think this should have the persist-credentials: false option added
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Add's https://pkg.pr.new workfow so users can test unreleased builds or test PR's before they are merged.
What is the current behavior? (You can also link to an open issue here)
Users have to clone and build if they want to test unreleased features
What is the new behavior (if this is a feature change)?
Users can now check the action output for a url that they can use to install a specific build of this package. For PR's a comment will be added to the PR thread with a url for the built package.
Other information:
A maintainer must also install/authorize the github app for this org. See https://pkg.pr.new for instructions.