-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added action to publish to npm on release #175
Changes from 2 commits
5907da9
642e5c7
462b985
c0db753
1715d65
ff58800
f91179f
388d833
34ff543
ea4ff22
30144ca
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,48 @@ | ||
name: Publish Cookie Policy release | ||
|
||
# Only for testing. Should be on: release: types: [published] | ||
on: | ||
- push | ||
|
||
jobs: | ||
build: | ||
name: Build Cookie Policy | ||
runs-on: ubuntu-latest | ||
steps: | ||
- uses: actions/checkout@v4 | ||
- uses: actions/setup-node@v4 | ||
with: | ||
node-version: 18 | ||
- name: Read cookie-policy version from package.json | ||
run: | | ||
node -p "require('./package.json').version" > CURRENT_VERSION | ||
echo "Building Cookie Policy v$(cat CURRENT_VERSION)" | ||
- run: yarn install | ||
- run: yarn build | ||
- run: yarn test | ||
- name: Show size of the build file | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is Vanilla specific and is not needed here |
||
run: stat -c '%s' build/css/build.css | ||
- run: cp CURRENT_VERSION build/css | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This also is likely Vanilla specific (we need this for publishing on assets server) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Definitely, I left it in because it seemed interesting, but it makes the process a bit longer |
||
- uses: actions/upload-artifact@v4 | ||
with: | ||
name: css | ||
path: build/css | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is Vanilla folder. This would need to be cookie-policy folder (dist?). But overall - I don't think you need to separate this into I think it would be simpler if you have it all in single job, just build/test first, and then attempt publishing to npm. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point, I'll merge the two together There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've merged the file, though the CI action failed because the current version was already published. It shouldn't be a problem though. |
||
|
||
publish-npm: | ||
name: Publish to NPM | ||
needs: build | ||
runs-on: ubuntu-latest | ||
steps: | ||
- uses: actions/checkout@v4 | ||
- uses: actions/setup-node@v4 | ||
with: | ||
node-version: 12 | ||
registry-url: https://registry.npmjs.org/ | ||
- if: ${{ !github.event.release.prerelease }} | ||
run: npm publish | ||
samhotep marked this conversation as resolved.
Show resolved
Hide resolved
|
||
env: | ||
NODE_AUTH_TOKEN: ${{secrets.NPM_TOKEN}} | ||
- if: ${{ github.event.release.prerelease }} | ||
run: npm publish --tag next | ||
samhotep marked this conversation as resolved.
Show resolved
Hide resolved
|
||
env: | ||
NODE_AUTH_TOKEN: ${{secrets.NPM_TOKEN}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if we want that yet, but could make sense to simply publish on every merge to main branch?
This would not create a release tag on GH (unless we can make it automated as well), but may be a nice next step in automating this, instead of relying on manual release.
This is the way we have it set up for our python packages that publish to pip, and in react components I think.
In Vanilla we want more manual control, so we tie it to GH release functionality. But here it probably will make it easier for everyone if it's fully automatic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like here: https://github.com/canonical/canonicalwebteam.flask-base/blob/main/.github/workflows/publish.yaml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree on the automation, and there should a way to create the release tag. In fact, we could
on merge to main.
I think this works for now though, and I can make another PR to set up the merge to main actions.