Hi all,
I have been working on the scripts to automate our release process. Here is
where things are at.
First, if you want to take a look at the scripts they are in my github repo
in a branch called "build_scripts":
https://github.com/jdeolive/geoserver/tree/build_scripts/build
Here is how they work. And I actually haven't setup all the hudson jobs
yet, but the underlying scripts are working. So here is how it will work.
On our main hudson server there is a job called "geoserver-release":
http://hudson.opengeo.org/hudson/job/geoserver-release/
The job takes the following parameters:
* branch to release from
* revision to tag
* release name
The underlying scripts actually take more parameters but i will get to
those later. When run the above job does the following:
1. creates the tag from the specified parameters
2. checks out the tag and preps for release, updating version numbers,
etc...
3. performs the main release build
4. assembles artifacts and uploads them to a distribution directory,
currently located here:
http://gridlock.opengeo.org/geoserver/release/
5. Fires off two installer jobs (one for windows, one for osx) on remote
hudsons. The two hudsons are currently on our internal network so i can't
provide access to them.
6. When the installer jobs complete they upload the artifacts to the same
distribution directory specified above.
The end result is all the artifacts wind up in a single directory matching
the release name. For example:
http://gridlock.opengeo.org/geoserver/release/2.2-beta2/
The above list of tasks is an overview, the main release script actually
does a bit more which is what i would like to discuss. The script also
checks jira and determines two things:
1. is the release actually released on jira
2. does the release have any open/unresolved issues filed against it
To do so it uses the jira rest api (which is nice btw). This is something I
would like feedback on. We have a couple of options here on what to do with
respect to jira.
1. don't do any checks against jira, and leave that a manual process
2. halt the build if the release is not released in jira or there are
unresolved issues, making releasing on a jira manually a precursor to
running the script
3. mark the release as released in jira, and push back any unresolved
issues to the next version
More options welcome.
The second thing I would like to discuss is how we handle the README.
Currently when we release we update the README on the main branch (and not
the tag). I would kind of like to avoid committing anything to the main
branch in an automated process. For example what happens if we run the
release, it fails and we run it again. We have to check if the readme has
been already updated, etc... While certainly possible with some script mojo
it seems like an error prone process I would like to avoid.
So what I would like to propose is the following. We don't ever update the
README on the main release branch. We leave it generic with information
about the project, where to find the docs, etc... On the tag we create we
would generate a new file called "RELEASE_NOTES.txt" (or something to that
effect) that contains the stuff we usually put in the README like revision
info and the new and noteworthy info for that release. To generate the new
and noteworthy for the release notes i was thinking we could come up with a
heuristic. One such heuristic could be to pull out any new feature or
improvement, and perhaps any issue that is a high priority one. Anyways,
you get the idea. And naturally it would contain the link to the entire
changelog from jira like we do now. Perhaps we should just stick to simple
and put the revision info and the changelog link in the release notes.
Probably what I will do for a first pass if people are into the idea.
Those are the two main things I need input on thus far. Aside from the
above stuff the main thing left to do is to do the upload to sourceforge. I
think this will be pretty straight forward. The idea is that there would be
a second release job (called geoserver-release-publish or something) that
would take the release tag as input and basically just upload all the
artifacts from the distribution directory to sourceforge. The idea is that
after the main release job (and the hudson installer jobs) complete the
person doing the release would do a quick sanity check on the artifacts,
fix issues, etc... Once completed the release publish job would do the
final push.
Oh, and another TODO will be to take the associated geotools info (version,
revision, etc...) and ensure that is what is included in the geoserver
build. I guess same goes for geowebcache as well.
That is it for now. Looking forward to hearing feedback.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
