search

silverstripe / webpack-config

Reusable webpack bundle declarations for Silverstripe modules
BSD 3-Clause "New" or "Revised" License
16 stars 9 forks source link

NEW Add GitHub Action for publishing to NPM #46

Closed Cheddam closed 1 year ago

Cheddam commented 4 years ago

This will trigger a publish of the module whenever we create a new release, saving time for the few developers with access to the @silverstripe NPM org.

~Requires a YARN_TOKEN secret to be added to the repository.~ (added)

Cheddam commented 4 years ago

This needs a little more thought - it relies on the version being set correctly in package.json, so still involves some double-handling. I'll look at adjusting it to either commit the new version back into package.json or to trigger the GitHub release based on the version being changed in package.json.

Cheddam commented 4 years ago

What will trigger a release?

Creating a new Release in GitHub.

What happens if version is not updated? Will it overwrite the old version in npm?

Excellent question - nope, it'll throw an error. I'll add docs on the release process to this PR.

emteknetnz commented 4 years ago

You could probably do something to get the latest tag name from the release

e.g. ${{ github.event.release.tag_name }} https://github.community/t/how-to-get-just-the-tag-name/16241/19 https://github.com/marketplace/actions/get-latest-tag

and then use that to populate yarn publish --new-version <version> https://classic.yarnpkg.com/en/docs/cli/publish/

Cheddam commented 4 years ago

The trouble with that is keeping the version in package.json up to date, which would require committing this back after the publish is triggered. I'm not sure how important it is to keep it in an accurate state, but I'd rather continue keeping it updated for now.

The foremost issue this automation intends to resolve is enabling releases from contributing / core committers who don't have access to the NPM organisation. We can look into more advanced tooling like semantic-release to further automate this process later.

GuySartorelli commented 1 year ago

We're doing away with the master branch to conform with the branching strategy we use on all our other repos - this PR will need to be updated to match, assuming we are still going ahead with this.

GuySartorelli commented 1 year ago

Closing since we simply haven't done anything with this, and we haven't been updating this with any frequency anyway. If this becomes a problem for us in the future we'll look at doing something like this again.