While I agree we should automate a lot, I agree with Eric. Doing a
Foreman release should involve a human to keep the end-to-end quality.
Just giving permissions is wrong.
For example in Foreman 1.15.5 the installer was tagged and released
before I could push in my changes. That communication failure might have
been partly my fault but IMHO the job of a release manager is to
communicate with all the maintainers if everything is in place for a
release.
Now you state it as a problem that you need a lot of people, but you
need to communicate with them anyway. Yes, the tagging and releasing
should be scripted but planning a release will require humans.
Like Eric I think we should start by documenting. Right now it's a huge
black box for most people, let's start there.
On Wed, Sep 27, 2017 at 09:19:10PM -0400, Eric D Helms wrote:
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.
--
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.
