[
https://issues.jboss.org/browse/MODCLUSTER-475?page=com.atlassian.jira.pl...
]
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)