Skip to content
This repository has been archived by the owner on May 28, 2019. It is now read-only.

Automate releases #208

Closed
charlierudolph opened this issue Apr 30, 2016 · 5 comments
Closed

Automate releases #208

charlierudolph opened this issue Apr 30, 2016 · 5 comments

Comments

@charlierudolph
Copy link
Contributor

charlierudolph commented Apr 30, 2016

Ideally I would hope the process could be:

  • update the version wherever needed (the ruby gemspec, the javascript package.json, etc...)
  • commit with a tag
  • on a tag, travis ci performs the following (once per language)
    • push each subtree and add a tag to each subtree
      • using a github auth token, belonging to a cucumber-bot account
    • publish
      • using a package manager auth key, belonging to a cucumber-bot account

Since we are no longer updating the subtree directly, the need for pulling the subtree should be removed.

Please let me know if you see any problems with this approach. If you think its sufficient, I'm happy to help get this up and running.

@charlierudolph
Copy link
Contributor Author

Travis has some built in help for automating releases to certain package managers. https://docs.travis-ci.com/user/deployment/

@aslakhellesoy
Copy link
Contributor

I haven't found a way to push tags to subtrees. And even if you found a way to do that, we shouldn't, because many (but not all) of the package managers perform tagging during a release.

Or maybe we could disable automatic tagging for all package managers?

Were you thinking that all releases would be made by travis' subtree builds?

@charlierudolph
Copy link
Contributor Author

Yes disable automatic tagging. And for tagging the sub tree, I would think the build could clone the sub tree repo after pushing it and just tag the latest commit.

@aslakhellesoy
Copy link
Contributor

Go for it and see what you can come up with!

@charlierudolph
Copy link
Contributor Author

Alright I'll try this for the javascript version to start. Two things I would like to have to start:

  • a github auth token (with write access to the the gherkin repos version, instructions)
  • a npm auth token (with publish access for the gherkin module, instructions)

For each I think we should create a cucumber-bot account. For that would probably be good to have them attached to a "cucumber.io" email.

Those could then be added as env variables here with the names GITHUB_AUTH_TOKEN and NPM_AUTH_TOKEN.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants