To release a gem to rubygems I'd recommend looking at how voxpupuli implemented this using Travis[1]. The same can be done for puppet[2]. That means you can push a tag to git and the release is there.

There are also tools that help you bump. For puppet there is puppet-blacksmith[3]. How to do annotated tags is in my notes[3]. A more generic script is bump2version[5] and I'm sure there are similar tools in the ruby world.

IMHO these tools should be suggested in the plugin templates.

[1]: 
https://github.com/voxpupuli/modulesync/blob/e53079030501756fc4111511fb9b6a239ffcb2a3/.travis.yml#L18-L27
[2]: 
https://github.com/voxpupuli/puppet-nginx/blob/fc363114e509f439b51ea22723a996ffca8a107d/.travis.yml#L48-L58
[3]: https://github.com/voxpupuli/puppet-blacksmith
[4]: http://pad-katello.rhcloud.com/p/releasing-modules
[5]: https://github.com/c4urself/bump2version

On Wed, Sep 27, 2017 at 08:08:46AM -0700, Daniel Lobato wrote:
For foreman-docker I had a process:

https://github.com/theforeman/foreman-docker/blob/master/release/RELEASE.md
https://github.com/theforeman/foreman-docker/blob/master/release/rollout-release

which I planned to implement in all theforeman org plugins ideally.
It didn't happen but it's a similar thing.

On Wednesday, September 27, 2017 at 4:56:51 PM UTC+2, Timo Goebel wrote:

... 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 <elob...@gmail.com
<javascript:>> 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...@googlegroups.com <javascript:>.
> 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.

--
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.

Reply via email to