auto deployments about single-spa-inspector HOT 6 CLOSED

Do tags correspond to the version in package.json? I think managing deployments based on that number would be ideal. Tags may be a proxy for that. That way we still merge to master as needed, bump the version, and not trigger unintentional builds (eg. make a change to the README, no need not deploy).

from single-spa-inspector.

It looks like we can trigger an action on a tag change https://help.github.com/en/articles/workflow-syntax-for-github-actions#onpushpull_requestbranchestags

doesn't appear to be any support for looking at the contents of package.json, at least at the moment. I could be wrong though.

from single-spa-inspector.

Tag is probably ok, I think npm version also creates a new tag so that should stay in lock-step. I looked around and didn't find any ready-made actions for deploying based on npm version.

from single-spa-inspector.

I just encountered an issue with basing deployments on tags, while at work. We use yarn version (though npm behaves the same so it should apply as well) to update the version numbers in package.json and yarn.lock, and this command also creates a git tag. We push those updates as part of a pull request and so the tag has a possibility of deploying a version that shouldn't yet go out.

from single-spa-inspector.

The way I've usually seen this done in open source projects is to only call yarn version (or yarn publish) on the master branch instead of on pull requested branches. Generally the pull requester doesn't update the version - that is done by the maintainer who is releasing a new version.

For single-spa-inspector, I think the above workflow would work well. Am open to whatever you and Anthony think would be easiest though for maintaining the project.

from single-spa-inspector.

Yea as long as we can commit directly to master, that would work (my company doesn't allow that for good reasons too).

from single-spa-inspector.