There are two considerations that I'd like to put forth as we think about this:
1) Instead of adding jobs, we re-think and re-write the release job in Pipeline syntax similar to my starter here -- https://github.com/theforeman/foreman-infra/pull/323 2) We don't automate all the things as there are some tasks that should be done by a human. The tedious, repetitive bits we should automate. The aspects that require some human foresight, approval or double checking of we should either require a releaser to "yes" to a job over or to perform semi-automated in that the user uses tooling but ultimately has input. For example, cherry picking should be 90% automated but 10% human input to ensure nothing seems off since our issue-to-change is not flawless. While we have some automation already in place, from my experience I would recommend one of the following approaches. 1) create a flow chart of every action that has to happen using something like plantuml with parallel actions where possible 2) Create a new release job, starting either from the beginning or the end of the process and add each next step to it Eric On Wed, Sep 27, 2017 at 10:46 AM, Daniel Lobato Garcia <elobat...@gmail.com> wrote: > Hi devs, > > After a few releases, and now that I'm trying to help someone else to > take over in case it's needed, I found a roadblock. > > Whoever is doing the release, needs to have **many** permissions. > > Otherwise, it doesn't make much sense for a person to take over release > responsibilities. For example, if Ondrej has to do 1.15.5, he would need > the following permissions (see at the end of the email). > > Of course there are alternatives: > > 1 is to have the release nanny be supervised by people who have 'earned' > these permissions. This is a bad idea because some of the tasks just > cannot be 'supervised'. The nanny would have to ask someone to tag > repositories, modify jenkins jobs, upload GPG signatures, post to the > mailing list, tag new builds in Koji... > > 2 is to extend http://ci.theforeman.org/view/Release%20pipeline/ and > make it a real pipeline from 0 to release completed. At this moment, > releases that are not the first RC1 are mostly automated by > https://github.com/dlobatog/foreman_release and > https://github.com/theforeman/tool_belt. > > My proposal is to go forward with 2. Give Jenkins permissions to do all > of the actions needed, and whoever is the release nanny, ideally only > has to make sure all of the steps are moving forward. If something > breaks, figure out how to fix it for the next release. > > This would mean making a few extra jobs before and after the current > release pipeline. In my opinion, it's the way to go to ensure anyone can > take over this responsibility. > > At this moment, we are in a situation where only people who > mostly have permissions everywhere can successfully do a release without > asking many people for favors. > > Personally if we complete this, I see it as a big win as it would dwarf > our bus factor for release managers & allow us to release at any pace we > desire (right now it's slow because we can't truly release things from > one day to the next due to the work involved). > > Thoughts? > > Here's the list of permissions: > > ---------------- > > Github: > - Push in foreman, foreman-selinux, foreman-installer, > smart-proxy, foreman-infra, foreman-packaging > > Transifex - > - Allow to change the auto-update URL to point to latest -stable > branch > > Redmine - > - Create new "Found in Release" version > > Jenkins - > - Modify jobs > - Run jobs > > Koji - > - Create tags > - SSH access to update the mash scripts > - Create packages > - Tag builds > > Repository servers > - ssh in deb.theforeman.org > - ssh in yum.theforeman.org > > Announcements - > - Post to foreman-announce > - Merge access in theforeman.org > - Change IRC message > - Publish in Twitter, G+ > > --------------- > > -- > Daniel Lobato Garcia > > @dLobatog > blog.daniellobato.me > daniellobato.me > > GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 > Keybase: https://keybase.io/elobato > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Eric D. Helms Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
