We should make release cutting an automated process

[majormoses]

There is imho way too much manual work being done in order to cut a release, I believe this is a major contributor to there often being very useful fixes and features added but have not been released.

I think we should simplify the release management to always cut a new tag and release on every pr to master. This means we can simply ensure that the submitter has the following:

1. bumped version accordingly with semver2 spec
2. Added their CHANGELOG entry; README if needed
3. Any code, tests, etc

If all goes well after maintainer review and merge it can be built without a maintainer having to pull down the repo, update CHANGELOG for missing entries, bump version, etc.

Rather than forcing the maintainers to do a bunch of manual steps that are of course error prone as we are terrible at following instructions where machines are great at doing exactly what we tell it. The other benefit is that users can immediately start pulling new changes if they want them. If we only had a few repos this would be less of an issue but we have a lots of repos. Also given the types of micro changes that typically happen in these projects it makes sense to me.

@mattyjones @portertech @eheydrick

[eheydrick]

I'm all for releasing after merging. We shouldn't let improvements sit in the repo unreleased. I'm curious how we'd handle versions between PRs. Like say we get 2 PRs targeting the same version - there'd be more back-and-forth required to coordinate releases and would potentially slow down getting stuff released if contributors are unresponsive, which happens a lot.

I've looked at automating changelogs with github-changelog-generator which is nice in that it removes the manual changelog updates and would cut out a lot of time. You have to be vigilant about PR/issue titles and labels since it generates from that. Something to think about.

[majormoses]

@eheydrick a very valid point, I Don't have a great solution off the top of my head but I will mull over it and maybe have something better after sleeping on it...

Bot driven off github messages (could be adapted for IRC, Slack, Hipchat controlled)

Bot message from maintainers trigger release job (seems overkill but conceptually fun):

1. user creates pr
2. some cr happens
3. maintainer wants to bless
4. maintainer messages @sensu-bot bump (major|minor|patch) which could be run multiple times and just use git commit --ammend to ensure we dont super inflate our history. Would also need to validate that the user it is coming from is a maintainer.
5. which could clone their repo, checkout their branch, make the version modification with something like the semver2 gem (would need to update the actual Gem version and the changelog message with version + header only), commit it to the branch, ci runs again
6. pr is merged/squashed/rebased into to master could auto tag and trigger gem build/publish

One potential issue with the approach above is that a user that does not allow maintainers to commit to their pr branches would break the bot. Though that seems trivial to explain to someone and could have some decent doc that we point them to.

Make it a single command release for maintainers

Another option is much less low tech (and effort) is to basically just have a Rake task to do the above and have it be still something manual kicked off by a maintainer but still reducing the amount of effort of the maintainers significantly. Having to git clone and rake bump:(major|minor|patch) is at least a move in the right direction then we could decide if we could have a bot drive that.

[mbbroberg]

When it comes to the toolchain here I think this repo is relevant. What do you think @mattyjones? https://github.com/sensu-plugins/gir

[majormoses]

I have only very quickly skimmed it over and it does some of the things outlined but I have not determined how much effort it would take to make this run in something like travis and be webhook/bot driven. It looks initially like it relies on vagrant which would not work in most virtual envs so I think this is still geared towards an actual maintainer running this locally but I could be missing something. I see some helpful rake tasks that are for sure what we are looking for.

[majormoses]

we might be able to port it over to be a docker container which would make it more easy to integrate in with travis or an ec2 env.

[mbbroberg]

I've been exploring tools and wonder if Atomist could help us: https://atomist.com/get-started.html

I like the ChatOps centric view and its dashboard. The challenge will be around TypeScript and whether we need to know it to get anything done. I'll reach out to them for their advice. Thoughts?

[majormoses]

Certainly looks interesting, I still feel like we probably should focus on making it a single action release with Rake first. The reason for this is that at the end of the day we are gonna need custom automation to make this work with atomist anyways so let's figure that out before bringing in a new tool into the mix.

[mbbroberg]

Sounds wise ✊

On Fri, Dec 29, 2017 at 10:19 AM Ben Abrams < Ben Abrams ( Ben Abrams notifications@github.com ) > wrote:

Certainly looks interesting, I still feel like we probably should focus on making it a single action release with Rake first. The reason for this is that at the end of the day we are gonna need custom automation to make this work with atomist anyways so let's figure that out before bringing in a new tool into the mix.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub ( https://github.com/sensu-plugins/community/issues/18#issuecomment-354481672 ) , or mute the thread ( https://github.com/notifications/unsubscribe-auth/ABqgS1xJYzSf1o9iX0Lsi0fXfrpTRXhoks5tFS1FgaJpZM4NO3JI ).

[sstarcher]

@majormoses fully agree the first step is a single command to do the release and a bot in the future could use that same command.

[mattyjones]

Atomist looks like a great tool, do we need all that though? A slack bot written in CS/JS that executes a rake task is fairly trivial. I am old school and have learned from my days of oh shiny to just go off the shelf and not reinvent the wheel.

Rake is ubiquitous and I strongly recommend it as a runner. If for some reason there is a need for something else with more teeth then go w/ make. If it can be good enough for the kernel it is good enough for this.

Once the whole mess is automated, then run it with a git hook. You can use a slack bot if you don't want to do the whole CI/CD thing and just want CI.

[majormoses]

Great points, here are my thoughts on them.

Atomist looks like a great tool, do we need all that though? A slack bot written in CS/JS that executes a rake task is fairly trivial. I am old school and have learned from my days of oh shiny to just go off the shelf and not reinvent the wheel.

Ya I am somewhere in the middle, to me it boils down to effort it takes to develop and maintain it not just the initial workload. If the pricing model makes sense and it reduces maintainers burden then I am all for using paid tools to save time. I'd personally prefer to spend my time maintaining plugins, cookbooks, utilities, etc than writing and maintaining a front end application in js.

Rake is ubiquitous and I strongly recommend it as a runner. If for some reason there is a need for something else with more teeth then go w/ make. If it can be good enough for the kernel it is good enough for this.

I wholeheartedly agree. I actually use make more than rake, I started adopting make as my standard a few years back when I started using docker. One interface to build, interact, etc on containers images, repos, etc without requiring any language specific deps outside of the container.

Once the whole mess is automated, then run it with a git hook. You can use a slack bot if you don't want to do the whole CI/CD thing and just want CI.

There is really only a few things that are left here. Currently it does deploy on tagged commits. This is my thoughts on what is left to do with rake:

1. changelog (version, create?, diff links)
2. version bump in file (should be trivial)

After that is where all the hard decisions come in, I think it makes sense to get to this point and have a discussion as there are way too many options to detail here and would best be served by a more real time discussion.