Listeners for build events

[Ahmed Omarjee <ah...@standardbank.co.za>]

Hi,

I have a requirement to perform other operations before checkout of a
project, as well as after a successful or failed build. 

The context of why I need this is as follows; I am using PVCS at a corporate
client, and have already begun writing a maven-scm-plugin for PVCS (I can't
sit around waiting for Serena to contribute their plugin). Using agile
methodology, I would normally perform a checkout, start the build process
(if changes are detected), and on successful build apply a label to the
source repository. But alas, PVCS does not have metadata locally thus a
label can not be applied to the version that was originally checked out,
which may result in inconsistencies.

A solution we have come it with (read hack), is : 

 - label the repository before checkout with a tag (eg. Building #123 -
01/07/2006 9:00)
- checkout using that label
- perform the build
- and on success rename the label (which strangely PVCS supports) (eg. Build
#123 - 01/07/2006 9:00)
- and on failure the label is removed (which strangely PVCS also supports)

If only we could have listeners to some important events such as build
start, on success, on failure, build finished, etc. this could be pluggable
behaviour.

I don't mind having a look at this and take up the challenge of maybe
implementing it, but I need some guidance and advice on the appropriateness
of this as a solution.

Ahmed
-- 
View this message in context: http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5267279
Sent from the Continuum - Dev forum at Nabble.com.

Re: Listeners for build events

[dan tran <da...@gmail.com>]

On 7/11/06, Ahmed Omarjee <ah...@standardbank.co.za> wrote:
>
>
> - IMHO, the act of checking code out, building and then labelling is not
> part
> of the typical developers build lifecycle (ie. on a single developers
> machine, he handles this kind of thing manually if needs be, by updating
> his
> codebase, labelling, and branching when required), this kind of automation
> is needed particularly when doing continuous integration.


True, that is why I have suggested to hook up Continuum with
maven-release-plugin to do the
automation.

- The release plugin could do the job but when does it run, where is it
> configured ?


Create a continuum shell project and configure build definition as

mvn release:release

this mojo is not avaible yet see
http://jira.codehaus.org/browse/MRELEASE-100

but I dont think it is hard to implement

- If I call the scm:tag command as part of a shell script integration in
> continuum, surely its build cycle is independent of the original project
> and
> hence may be inconsistent. Somehow the entire build cycle for a given
> project should be a single unit of work, all the way from checkout, build,
> test, and then potentially apply a label.


scm:tag does the label

scm:bootstrap pulls the source  just labeled

how could it inconsitent?


Ahmed
>
>
>
>
> --
> View this message in context:
> http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5272261
> Sent from the Continuum - Dev forum at Nabble.com.
>
>

Re: Listeners for build events

[Ahmed Omarjee <ah...@standardbank.co.za>]

My humble opinion is that some sort of listener implementation can help us
consider the entire build cycle as  a "unit of work" in a pluggable and
reusable fashion by raising and then acting on an appropriate set of events.
-- 
View this message in context: http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5272303
Sent from the Continuum - Dev forum at Nabble.com.

Re: Listeners for build events

[Ahmed Omarjee <ah...@standardbank.co.za>]

- IMHO, the act of checking code out, building and then labelling is not part
of the typical developers build lifecycle (ie. on a single developers
machine, he handles this kind of thing manually if needs be, by updating his
codebase, labelling, and branching when required), this kind of automation
is needed particularly when doing continuous integration.

- The release plugin could do the job but when does it run, where is it
configured ?

- If I call the scm:tag command as part of a shell script integration in
continuum, surely its build cycle is independent of the original project and
hence may be inconsistent. Somehow the entire build cycle for a given
project should be a single unit of work, all the way from checkout, build,
test, and then potentially apply a label.

Ahmed




-- 
View this message in context: http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5272261
Sent from the Continuum - Dev forum at Nabble.com.

Re: Listeners for build events

[dan tran <da...@gmail.com>]

On 7/11/06, Ahmed Omarjee <ah...@standardbank.co.za> wrote:
>
>
> Some questions:
>
> - Should the continuous integration tool not take the responsibility for
> performing the labelling, since it checked out the code, reports and
> notifies interested parties on success or failure of the compilation and
> tests against that code ?


Not neccessary, IMO since it already has some other mean to do it

- In my mind the fact that I have built and run my tests successfully does
> not necessarily equate to me making a release. Any thoughts ?


behind the scene, release plugin, in general, label the source, validate the
build.
It can be reused for other purposes where label is required for each build.


- Lastly, how can I automate the act of labelling if this is not part of the
> continuous build process?


Create continuum shell project and configure this command to run

mvn scm:tag -Dtag=sometag scm:bootstrap -Dgoals=install

never try it thou

You may need to write a custom plugin to automate the tagname generation.



Ahmed
>
> http://www.nabble.com/forum/ViewPost.jtp?post=2736062&framed=y
> --
> View this message in context:
> http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5271292
> Sent from the Continuum - Dev forum at Nabble.com.
>
>

Re: Listeners for build events

[Ahmed Omarjee <ah...@standardbank.co.za>]

Some questions:

- Should the continuous integration tool not take the responsibility for
performing the labelling, since it checked out the code, reports and
notifies interested parties on success or failure of the compilation and
tests against that code ?

- In my mind the fact that I have built and run my tests successfully does
not necessarily equate to me making a release. Any thoughts ?

- Lastly, how can I automate the act of labelling if this is not part of the
continuous build process?

Ahmed

http://www.nabble.com/forum/ViewPost.jtp?post=2736062&framed=y
-- 
View this message in context: http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5271292
Sent from the Continuum - Dev forum at Nabble.com.

Re: Listeners for build events

[dan tran <da...@gmail.com>]

I think you should let maven-release-plugin do to this work for you provided
that
you have all required maven-scm-api interface implemented

-D


On 7/11/06, Ahmed Omarjee <ah...@standardbank.co.za> wrote:
>
>
> Hi,
>
> I have a requirement to perform other operations before checkout of a
> project, as well as after a successful or failed build.
>
> The context of why I need this is as follows; I am using PVCS at a
> corporate
> client, and have already begun writing a maven-scm-plugin for PVCS (I
> can't
> sit around waiting for Serena to contribute their plugin). Using agile
> methodology, I would normally perform a checkout, start the build process
> (if changes are detected), and on successful build apply a label to the
> source repository. But alas, PVCS does not have metadata locally thus a
> label can not be applied to the version that was originally checked out,
> which may result in inconsistencies.
>
> A solution we have come it with (read hack), is :
>
> - label the repository before checkout with a tag (eg. Building #123 -
> 01/07/2006 9:00)
> - checkout using that label
> - perform the build
> - and on success rename the label (which strangely PVCS supports) (eg.
> Build
> #123 - 01/07/2006 9:00)
> - and on failure the label is removed (which strangely PVCS also supports)
>
> If only we could have listeners to some important events such as build
> start, on success, on failure, build finished, etc. this could be
> pluggable
> behaviour.
>
> I don't mind having a look at this and take up the challenge of maybe
> implementing it, but I need some guidance and advice on the
> appropriateness
> of this as a solution.
>
> Ahmed
> --
> View this message in context:
> http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5267279
> Sent from the Continuum - Dev forum at Nabble.com.
>
>

Re: Listeners for build events

[Ahmed Omarjee <ah...@standardbank.co.za>]

Agreed. Just to confirm that this listener based approach is indepedent of
the current notifiers based approach with respect to its intended use. (not
necessarily drastically different with respect to implementation).
-- 
View this message in context: http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5284666
Sent from the Continuum - Dev forum at Nabble.com.

Re: Listeners for build events

[Trygve Laugstøl <tr...@apache.org>]

Ahmed Omarjee wrote:
> Thanks for your response. Glad to hear that a listener based approach is a
> viable solution. I have already obtained the source from Subversion trunk
> and will begin looking at implementing such an approach. 
> 
> Any thoughts on the events people may want to listen on?

Are there any but:

- before scm update
- after scm update

There are already notifiers for the other build events so you can do 
additional operations there.

--
Trygve

Re: Listeners for build events

[Ahmed Omarjee <ah...@standardbank.co.za>]

Thanks for your response. Glad to hear that a listener based approach is a
viable solution. I have already obtained the source from Subversion trunk
and will begin looking at implementing such an approach. 

Any thoughts on the events people may want to listen on?
-- 
View this message in context: http://www.nabble.com/Listeners-for-build-events-tf1923745.html#a5284524
Sent from the Continuum - Dev forum at Nabble.com.

Re: Listeners for build events

[Trygve Laugstøl <tr...@apache.org>]

Ahmed Omarjee wrote:
> Hi,
> 
> I have a requirement to perform other operations before checkout of a
> project, as well as after a successful or failed build. 
> 
> The context of why I need this is as follows; I am using PVCS at a corporate
> client, and have already begun writing a maven-scm-plugin for PVCS (I can't
> sit around waiting for Serena to contribute their plugin). Using agile
> methodology, I would normally perform a checkout, start the build process
> (if changes are detected), and on successful build apply a label to the
> source repository. But alas, PVCS does not have metadata locally thus a
> label can not be applied to the version that was originally checked out,
> which may result in inconsistencies.
> 
> A solution we have come it with (read hack), is : 
> 
>  - label the repository before checkout with a tag (eg. Building #123 -
> 01/07/2006 9:00)
> - checkout using that label
> - perform the build
> - and on success rename the label (which strangely PVCS supports) (eg. Build
> #123 - 01/07/2006 9:00)
> - and on failure the label is removed (which strangely PVCS also supports)

Sounds good as long as all of the steps are optional and configurable.

> If only we could have listeners to some important events such as build
> start, on success, on failure, build finished, etc. this could be pluggable
> behaviour.

Correct, this will happen before a build is even started.

> I don't mind having a look at this and take up the challenge of maybe
> implementing it, but I need some guidance and advice on the appropriateness
> of this as a solution.

That would be great if you would like to take a look just beware that it 
won't be a trivial task and will take a while. This is something that 
has been requested several times and is something I think would be nice 
to add.

To get started check out the Continuum code from trunk [1] and try to 
build it with ./build.sh. You might have to download some dependencies 
from Sun or likewise places but Maven should inform you.

[1]: https://svn.apache.org/repos/asf/maven/continuum/trunk/

--
Trygve