The above will run for master OR tag v*. In order to run for just tags, I need to ignore wildcard branches, but it seems like that would run for tags matching the regex on any branch, so I (or anyone else) could push a tag to a feature branch and end up publishing to npm.
I'm considering writing or finding a utility to do the deployment only for the master branch on commit when the package.json version has upgraded compared to the latest version on the NPM repository.
This whole "manually push a tag that doesn't even have to match the the version you set in a possibly very old pull request" workflow is not what I want at all anyway. My goal is continuous deployment based on a democratic process like a pull requests. Pushing tags is manual and unilateral -- I might as well be running yarn publish from the console.
Problems with the current approach:
I could merge a PR that updates the version, merge 4 more PRs, then push the tag and cause publication of those 4 features.
I could push a tag like v9.9.9 to branch feature/foo and cause publication I think?
As far as I can tell, looking at the ci config for girder, if I pushed a random tag version to a random branch of girder, it would get published to pypi. It doesn't look like there's any requirement in the release workflow that the branch be master.
68 broke CI because I fundamentally don't understand filtering.
Need to read https://circleci.com/docs/2.0/workflows/#executing-workflows-for-a-git-tag a few more times.
The above will run for master OR tag
v*. In order to run for just tags, I need toignorewildcard branches, but it seems like that would run for tags matching the regex on any branch, so I (or anyone else) could push a tag to a feature branch and end up publishing to npm.I'm considering writing or finding a utility to do the deployment only for the master branch on commit when the package.json version has upgraded compared to the latest version on the NPM repository.
This whole "manually push a tag that doesn't even have to match the the version you set in a possibly very old pull request" workflow is not what I want at all anyway. My goal is continuous deployment based on a democratic process like a pull requests. Pushing tags is manual and unilateral -- I might as well be running
yarn publishfrom the console.Problems with the current approach:
feature/fooand cause publication I think?As far as I can tell, looking at the ci config for girder, if I pushed a random tag version to a random branch of girder, it would get published to pypi. It doesn't look like there's any requirement in the release workflow that the branch be master.