Travis tags releases when running in a RELEASE_BRANCH

[gobengo]

This is an automated way of managing git tags (a.k.a. releases) in an automated way using GitHub conventions.

This PR establishes a new + automated release workflow

• to work on a new feature, do what you probably already do: fork a new branch 'feature' off master, write some code, and push to github.
• Travis will find out, and run a build for your feature branch. As part of new code here, it will also check to make sure that the package.json version number does not correspond to an exissting git tag. i.e. you need to increment package.json version number to an unreleased version in order to start devving new features.
  • So if your build failed because of this, you'd just make a change to package.json, commit, and push. Travis would rebuild and hopefully succeed.
• Someone else looks at your PR and merges it to master. Travis would kick in again for the master branch. Now your feature branch is incorporated in master for others to take advantage of.
• There is also now a 'release' branch, though. And with this we can explicitly open a pull request from master -> release in order to propose a new 'release' of the project. GitHub issue comments can be used for discussion and consensus building.
• Upon merge to 'release branch', travis can automate release actions. After this PR, the only release action would be to create the git tag for the new release (based on value of package.json version), and push the tag to github. This automates the tagging process so humans don't have to all try to do it the same.

What this enables:

• With well-defined version numbers and release timeline, it is much easier to get useful bug reports, investigate causes of errors, and describe how to make use of new fixes and improvements
• Other triggers off of this 'release' branch. For example, we could always iterate fast on 'master' branches, and have that CD to staging branch. We could have production CD off of 'release' branch, with each release to production having a version number. This way we can have pull requests for major releases to production, including conversation about how/when to deploy.

New build functionality

• build/travis/origins/* - Travis loads environment variables for any configured github origins. This is useful to load travis-ci encrypted values. In our case this will be an SSH private key (registered as deploy keys in GitHub) used to authenticate with github over ssh when doing git remote things. This makes it so any number of forks can use this git-pushing functionality of the build.
• build/check_npm_version - The build should fail when the package.json's version is already taken by a released tag of the same name (and the build is not running on the same commit as that tag)
• build/tag_release - When building commits on the RELEASE_BRANCH (defaults 'release'), succesful builds should lead to a new git tag being created and pushed to GitHub. This makes the developer interface to creating new releases as simple as a Pull Request (example). Travis will also remind developers to bump the package.json version as new releases go out.

[eenblam]

@gobengo I'm pretty sure this will keep failing on Travis while this branch is on your fork. Can you push to sudomesh:travis-tags and reopen?

https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions

[gobengo]

I did not repush, but I made the build pass in sudomesh org.

[bennlich]

Sorry I missed this @gobengo . I don't think I totally understand what this PR does. Would you be up for chatting online or in person about it?

[gobengo]

Yep. Let's put on agenda for 6/20 software WG meeting (a general discussion on bug 34 perhaps).

Helping my mom move through the end of the week in Poland but I'll watch for you on chat when in online to discuss sooner.

On Mon, Jun 11, 2018, 10:57 AM Benny Lichtner notifications@github.com wrote:

Sorry I missed this @gobengo https://github.com/gobengo . I don't think I totally understand what this PR does. Would you be up for chatting online or in person about it?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sudomesh/monitor/pull/23#issuecomment-396171706, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKfBiEFoiy6VT8OGCIOyOm_zJl74j_3ks5t7jDqgaJpZM4T-Swn .

[bennlich]

Yep. Let's put on agenda for 6/20 software WG meeting (a general discussion on bug 34 perhaps).

Sounds great! Would be 6/19 I think? The tuesday?

Helping my mom move through the end of the week in Poland but I'll watch for you on chat when in online to discuss sooner.

Kk. Good luck with the move!! Bring back Polish treats? :yum:

[gobengo]

@bennlich treats procured

[gobengo]

Bennie and I just synced on this work. I think everyone involves agrees that while the workflow changes may be appropriate for more critical components like sudowrt-firmware, they are overkill for this repo. I'm closing this issue, but may re-propose a similar one for sudowrt-firmware.