On 23 Aug 06, at 10:02 AM 23 Aug 06, Brett Porter wrote:
Finally getting around to replying :)
I spoke to Edwin on IRC and he's proposed the following steps:
1) go to the project group...
2) then click on the release project icon ( a new icon )
3) then a page will prompt for the release version and the next dev
version...
4) after filling the required parameters, click the prepare for
release button...
5) the page after the procedure is either a progress or an auto-
refreshing page, i'm still open )
6) when the release prepare is a success, then a button for the
perform release is shown
7) otherwise, some kind of a build failure report will be shown
8) and repeat 6/7 during perform release
The original proposal was web services based, but the entire process
occurring from Continuum is definitely useful. I think the concrete
drivers are:
1) release:prepare from the CLI with the release plugin and pushing a
release descriptor to Continuum. Then using the Continuum Web UI to
perform the release.
2) talking to continuum via web services from an IDE to do the
release:prepare. Then using the Continuum Web UI to perform the release.
3) talking to continuum via web services from an IDE to do both the
release:prepare and release:perform.
4) the case noted above
The the WEB UI needs to cleanly account for the separation so that
the perform is not tied to the preparation being done in the web ui.
So this part is pretty straightforward. For 3) the webwork
modeldriven action can be used against the modello model to easily
produce a form page. For 5) the WW showcase has a "run in
background, show page and refresh" example that could be used,
though I consider that a nice to have.
There seems to be a pretty good base with the current model. I
think the tasks that are needed in the release plugin:
- add any missing elements to the model
- change the release mojos to marshal arguments to this instead of
the current configuration classes and pass that into the release
process
- need to retain the ability to prompt for those not specified as
happens now, so the prepare(Release) method will be new. Continuum
will set the mojo into non-interactive mode to ensure this doesn't
happen.
- flesh out the release descriptor which is used for a release
- flesh out the release manager component and it can just delegate to
the release plugin i suppose though separating a release manager
component as has been discussed with Jeremy I think would be a good
thing to do.
And in continuum its wiring up the steps as above. Edwin was going
to make adjustments to the white site to be able to visualise this
before diving in.
Cool, I think Jeremy has some general ideas too and Edwin and Jeremy
can sort out how they want to implement the details.
The tricky things that might need more discussion:
- how are multi-module projects handled in Continuum? I think for
this incarnation we go with the simple solution which is to just
trigger it on the project on its merits (so if its the parent, the
whole lot is released)
For a multi module build when would you not use the parent? If you
wanted a specific component that could be recorded in the release
descriptor.
- how is the project built? Is it queued into Continuum, or are the
same tools used to run a separate build in the background?
- what files are modified? the current checkout in Continuum, or a
clean one? If it is the current one, builds need to be locked out
while the release process is in progress.
A release build is different then what Continuum is typically doing
so some separation I think would be wise so that in the UI release
specific builds could be identified so possibly a separate queue with
some different parameters so that release builds can't be interfered
with.
I think the short term solution is to go with a clean checkout and
doing it all in the background, separate from the continuum build
queue. This seems the easiest.
Separate from the standard CI queue but I think a release queue would
be appropriate. Then we could leverage all the reporting and screens
for builds in queues.
In the long term, has Continuum becomes more feature rich, I would
rather see it is a queued build with certain settings enabled
(clean checkout, clean repository) so that other features such as
monitoring the scheduling could be reused.
Ok, I should just read ahead :-)
I think we should think about this now instead of hacking out
something. Jeremy and Edwin seem to have some time so let's address
all the points outlined above. Have some feedback on design, which
shouldn't take long, and then implement.
Thoughts?
How could the work be partitioned up so that both interested people
can work on it effectively?
I think as long as all the design, which I'm sure both Jeremy and
Edwin will contribute to, is out on the table and we all agree then
they can work out the implementation. I think as they are both
relatively new contributors this is the best course forward.
Cheers,
- Brett
On 12/06/2006, at 1:46 PM, Jeremy Whitlock wrote:
Continuum Dev,
I am currently working on a mechanism to have Maven's release
plugin to
actuall use Continuum to perform the release process in a "Release
Management" type of usage. Jason Van Zyl and I have talked about
this for
the last few days to flesh out the approach and here are the two
Jira that
should get you up to speed with what I am doing:
http://jira.codehaus.org/browse/CONTINUUM-727
http://jira.codehaus.org/browse/MRELEASE-130
Jason has given me some good tips and such and I plan on starting
this
tomorrow sometime. If any of you have any concerns, complaints or
suggestions, please let me know.
Take care,
Jeremy
Jason van Zyl
[EMAIL PROTECTED]
