... isn‘t continuous delivery old these days? Why aren‘t we doing it? I vote in favor of automating this. This ensures predictable results and hopefully makes this process easier. To be honest: The current process scares me. Same for plugin releases. They also are way too manual right now.
Timo > On 27. Sep 2017, at 16:46, 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. -- 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.
