[mod_cluster-issues] [JBoss JIRA] (MODCLUSTER-475) Automate built artifacts release to GitHub Releases

[Michal Karm Babacek (JIRA)]

     [ https://issues.jboss.org/browse/MODCLUSTER-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Karm Babacek updated MODCLUSTER-475:
-------------------------------------------
    Description: 
The current setup of the suite of our multi-platform Jenkins jobs builds all the release artifacts without pushing them anywhere.

The person doing the release has to download all these built artifacts and upload them to the jboss.org. Next, one has to adjust Magnolia Release pages, Release notes and links. It is tedious, it involves extensive Magnolia and Docbook hacking and we should get rid of it in order to streamline the release process.

MODCLUSTER-474 introduced GitHub Releases, e.g. [1.3.1.Final on GitHub|http://modcluster.io/change_log/#final-6-may-2015]. This particular "demo" was uploaded manually, although it could be nicely automated either with [ghr|https://github.com/tcnksm/ghr] or [github-release|https://github.com/aktau/github-release]. The only possible downside is the exposure of our GitHub keys to the build environment. It could be easily addressed by having the mod_cluster-release Jenkins job tied to a one and only one specific private slave. Other suggestions are welcome though.

Also, let's avoid https://xkcd.com/1319/

  was:
The current setup of the suite of our multi-platform Jenkins jobs builds all the release artifacts without pushing them anywhere.

The person doing the release has to download all these built artifacts and upload them to the jboss.org. Next, one has to adjust Magnolia Release pages, Release notes and links. It is tedious, it involves extensive Magnolia and Docbook hacking and we should get rid of it in order to streamline the release process.

MODCLUSTER-474 introduced GitHub Releases, e.g. [1.3.1.Final on GitHub|http://modcluster.io/change_log/#final-6-may-2015]. This particular "demo" was uploaded manually, although it could be nicely automated either with [ghr|https://github.com/tcnksm/ghr] or [github-release|https://github.com/aktau/github-release]. The only possible downside is the exposure of our GitHub keys to the build environment. It could be easily addressed by having the mod_cluster-release Jenkins job tied to a one and only one specific private slave. Other suggestions are welcome though.



> Automate built artifacts release to GitHub Releases
> ---------------------------------------------------
>
>                 Key: MODCLUSTER-475
>                 URL: https://issues.jboss.org/browse/MODCLUSTER-475
>             Project: mod_cluster
>          Issue Type: Task
>            Reporter: Michal Karm Babacek
>            Assignee: Michal Karm Babacek
>
> The current setup of the suite of our multi-platform Jenkins jobs builds all the release artifacts without pushing them anywhere.
> The person doing the release has to download all these built artifacts and upload them to the jboss.org. Next, one has to adjust Magnolia Release pages, Release notes and links. It is tedious, it involves extensive Magnolia and Docbook hacking and we should get rid of it in order to streamline the release process.
> MODCLUSTER-474 introduced GitHub Releases, e.g. [1.3.1.Final on GitHub|http://modcluster.io/change_log/#final-6-may-2015]. This particular "demo" was uploaded manually, although it could be nicely automated either with [ghr|https://github.com/tcnksm/ghr] or [github-release|https://github.com/aktau/github-release]. The only possible downside is the exposure of our GitHub keys to the build environment. It could be easily addressed by having the mod_cluster-release Jenkins job tied to a one and only one specific private slave. Other suggestions are welcome though.
> Also, let's avoid https://xkcd.com/1319/



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)