On 08/07/2008, at 1:47 AM, John Casey wrote:
Jason's referring to a ruby script I wrote to lookup the version
string for a particular staged project, for use in the stage:copy
mojo. This allows us to setup generic promotion scripts in a CI
environment like Hudson. I've committed this script to: https://svn.apache.org/repos/asf/maven/sandbox/trunk/scripts
.
So basically it's a simple way to do http to http repository copies
instead of http to scp?
The rest of this release infrastructure has simply been
configuration of hudson and nexus - nexus, to provide a staging
ground for releases - to configure release jobs that deploy to this
staging location instead of the real release repository...just
generalizing on configuration that we all have in our personal
settings.xml files by now. Jason's credentials are used for SVN and
SSH where necessary, and I've created a new GPG key for use in this
CI system, then signed it with my own key. That key ID is: 84B54612.
Sorry, but I'm not at all comfortable with this.
Firstly, it rules out both of our current Hudson instances, since it
gives access to people outside the project to be able to read our
private release key. I'm not even sure about the wisdom of using a
shared key vs. an individual one and would want to ask someone with
more experience.
Secondly, it gives others access to Jason's account on
people.apache.org that are not Jason, as well as losing the
information of who deployed it.
There are other ways to handle the second part if we do have a
canonical release repository on a different machine to the present one
(namely, a user initiated pull from people which is easy enough).
But the question of how you sign something there is something that
would need to be addressed. These challenges are the reason I haven't
suggested using Continuum's built-in release mechanism for our
releases over all the time it has been available.
Maybe we could run whatever the final proposal is past the ASF
security and infrastructure teams?
To echo Jason, the goal here is to create an environment that - if
not perfectly flawless - is at least a known quantity. Just as we've
moved in the direction of pointing to our CI servers as the
definitive point of reference for our unit and integration tests
(though we're not quite there yet), we need to be releasing Maven
artifacts from a similarly definitive environment. In principle, the
configuration and script I've written (above) should enable any team
to enable a similar release infrastructure for their own projects.
I certainly understand the drive to it - it's the first thing I set up
in most environments (way back to when I got burned by this in the m1
days).
But on the other hand, like you said, we're not even there with CI
yet. I do hope that with an increased push towards determinism in the
artifact resolution this becomes less of an issue.
Right now, I feel like our efforts would be better spent in tooling to
validate releases wherever they come from.
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
