feat(release): add automatic git tagging

whyrusleeping / gx

A package management tool

MIT License

1.88k stars 111 forks source link

feat(release): add automatic git tagging #207

Open dignifiedquire opened 5 years ago

dignifiedquire commented 5 years ago

uses command line for now, to avoid introducing new dependencies and get something working now
currently can not be disabled, always uses the default, needs likely discussion what to do here, see todo in the code
command is configurable through tagCmd
no signing, could be added by everyone who wants, by modifying the tagCmd

Ref #157

Stebalien commented 5 years ago

Do we really need a separate tagCmd? Can we not just run two commands in the release command hook?

hsanjuan commented 5 years ago

Please don't change default behaviour of gx release (don't do auto-tagging). It might break integrations which do tagging separately. (I think it's probably fine as it is now, assuming it doesn't tag when using legacy package.json without the tagCmd defined).

Stebalien commented 5 years ago

I'm definitely not suggesting that we replace existing releaseCmd definitions, just that new package.json files (generated by gx init) should have new releaseCmd definitions that auto-tag. The tricky part is running two commands without, e.g., depending on bash (although I guess that may be fine).

raulk commented 5 years ago

Now that we're introducing different tag namespaces to distinguish gx vs. gomod version lineages, we need gx to create the tag to mitigate the chance of human error.

My concern with piling the tag command into the releaseCmd is that we'd need to go back and rewrite all package.json files of all repos to opt into tagging.

On the contrary, the tagCmd solution with a default fallback is immediately applicable to all repos.

BTW – gx should remind the user to use the --tags option when pushing, if a tag was created.

cc @Kubuxu

Stebalien commented 5 years ago

That assumes that the user has a git-based releaseCmd. If not, this'll end up tagging the commit before the package changes are committed.

I'm perfectly happy to mass-update the releaseCmd if we merge https://github.com/whyrusleeping/gx/pull/227.

raulk commented 5 years ago

@Stebalien I approved that PR (non-binding). If we're OK with the rewrite, then I'm fine as long as we explicitly echo "please push with --tags" as a reminder because I can see us tripping up more than once.

Stebalien commented 5 years ago

SGTM. So:

git commit -a -m \"gx publish $VERSION\" && git tag -as -m \"gx publish $VERSION\" gx/v$VERSION && echo \"Please remember to push with '--tags'\"

raulk commented 5 years ago

I'd state the hash in the tag message, as the version number is redundant because it's part of the tag name. Other than that, LGTM.

Stebalien commented 5 years ago

So, the tag message is often (e.g., on GitHub) used as the tag's title. However, we should probably put the hash on the second line of the message. We'll need https://github.com/whyrusleeping/gx/pull/228 for that.