9 Replies Latest reply on Feb 21, 2011 8:18 AM by objectiser

Hudson jobs for git repos

objectiser Feb 20, 2011 8:07 AM

Now that the core bundles are separated into a separate git repository, I have also setup a separate hudson job to build these bundles.

The idea being that hudson jobs will also be setup for the savara-integration and savara-tools-eclipse repositories, which will be dependent (and therefore triggered) by the savara-core hudson job, to propagate changes that may occur in the core bundle, and ensure there is no adverse effect on the two jobs that use those bundles (i.e. integration and tools eclipse).

The issue is that each of these jobs could be run on different servers, and even if not, they each use a local maven repository, to ensure suitable isolation from other jobs running on the server.

So (for example), a change may be applied to the core bundles, which will trigger a core build, which would then propagate to trigger a build of the integration and eclipse tools projects. However these dependent projects would pull in the latest snapshot artifacts from the Nexus repo, as opposed to the latest version of the core bundles built by the other hudson job.

One approach might be to publish the snapshot on each successful completion of the savara-core hudson job? Not sure if this is possible, and how it would be configured.

However even if this was possible, we would need to consider whether this should only occur on snapshots, or whether it would be valid for releases aswell? Although Nexus would be holding the non-snapshot artifacts in a staging area, so the other hudson jobs may not be able to access them without some manual changes.

Thoughts?

1. Hudson jobs for git repos

objectiser Feb 20, 2011 8:10 AM (in response to objectiser)

The easiest solution would be to build the savara-core bundles as part of each of the dependent jobs? This may be a workable solution for the nightly builds, but might cause problems when doing releases.
Actions
2. Hudson jobs for git repos

objectiser Feb 20, 2011 10:10 AM (in response to objectiser)

One issue with this approach is that the hudson job configuration allows multiple git repositories to be defined, but you can only specify a sub-folder once in the git section, not on a per repository basis.

So the fetched repositories would be overwriting common files in the top level folder (e.g. pom.xml).
Actions
3. Hudson jobs for git repos

jeff.yuchang Feb 20, 2011 8:22 PM (in response to objectiser)

Gary Brown wrote:

One approach might be to publish the snapshot on each successful completion of the savara-core hudson job? Not sure if this is possible, and how it would be configured.

However even if this was possible, we would need to consider whether this should only occur on snapshots, or whether it would be valid for releases aswell? Although Nexus would be holding the non-snapshot artifacts in a staging area, so the other hudson jobs may not be able to access them without some manual changes.

Thoughts?
Will the ' Trigger parameterized build on other projects' option in the Hudson job help? we can attach these three nodes into one hudson node, without by specifying the maven repo, these three maven repository can be shared, I believe.

Personally, I would prefer publishing the snapshot on eacu successful completion of savara-core. One possible is that we can use the 'Invoke batch tasks ' option to run the 'mvn clean deploy', one drawback would that we have to use a username & password to be able to publish the snapshots. :-(

Regards
Jeff
Actions
4. Hudson jobs for git repos

objectiser Feb 21, 2011 4:13 AM (in response to jeff.yuchang)

Triggering the dependent builds is useful if the dependent build can pick up the latest version of the core artifacts. Don't really want to rely on the same hudson node being used with shared local repo.

I think publishing using the exec script should be ok, as I presume the exec script will not be executed if the previous step fails?

In the case of the savara-core job, I think we could just manually publish releases, to avoid having to configure hudson with nexus username/password.
Actions
5. Hudson jobs for git repos

jeff.yuchang Feb 21, 2011 5:02 AM (in response to objectiser)

Gary Brown wrote:

I think publishing using the exec script should be ok, as I presume the exec script will not be executed if the previous step fails?
Yes, it wouldn't be executed if the previous step fails.
Gary Brown wrote:

In the case of the savara-core job, I think we could just manually publish releases, to avoid having to configure hudson with nexus username/password.
Are you saying that manually publishing the snapshot? if it is, then we don't need to have the post build exec task to do the publishing, right? I am not clear on this.
Actions
6. Hudson jobs for git repos

objectiser Feb 21, 2011 5:19 AM (in response to jeff.yuchang)

No I'm suggesting that we do the publish step - when it is a snapshot version it will deploy ok, but if a non-snapshot version, then it would fail. So in this case we would do a manual publish outside of hudson.
Actions
7. Hudson jobs for git repos

jeff.yuchang Feb 21, 2011 5:23 AM (in response to objectiser)

I could be wrong here, but AFAIK, publishing the snapshot also requires the username and password, which we used to define in our local maven/conf/settings.xml .
Actions
8. Hudson jobs for git repos

objectiser Feb 21, 2011 5:33 AM (in response to jeff.yuchang)

Not sure, as I tried this out and the deploy failed, but not on the first one - so seems to indicate it was able to publish the snapshot for some of the modules. Just need to investigate why it had problems later.
Actions
9. Hudson jobs for git repos

objectiser Feb 21, 2011 8:18 AM (in response to objectiser)

Looks academic at the moment, as when I run the snapshot deploy from my local environment (with a nominated clear local repo folder), it works fine - but in the hudson environment it fails with:

[INFO] ------------------------------------------------------------------------
[INFO] Building Savara::Bundles::ActivityValidatorCDM
[INFO] task-segment: [clean, deploy]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting directory /mnt/hudson_workspace/workspace/savara-core-master/sources/bundles/org.savara.activity.validator.cdm/target
[INFO] [resources:resources]
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /mnt/hudson_workspace/workspace/savara-core-master/sources/bundles/org.savara.activity.validator.cdm/src/main/resources
[WARNING] POM for 'org.pi4soa:org.pi4soa.common:pom:3.1.0.Final:compile' is invalid. It will be ignored for artifact resolution. Reason: Cannot find layout implementation corresponding to: 'p2' for remote repository with id: 'jbosstools-nightly-trunk'. for project org.jboss.tools:org.pi4soa.common at Artifact [org.pi4soa:org.pi4soa.common:pom:3.1.0.Final:compile]
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).

Project ID: org.jboss.tools:org.jboss.tools.parent.pom

Reason: Cannot find layout implementation corresponding to: 'p2' for remote repository with id: 'jbosstools-nightly-trunk'. for project org.jboss.tools:org.jboss.tools.parent.pom

So for now I will remove this step, and so have to treat each project as separate - so if the Eclipse tools or integration job need to access updated core artifacts, these will need to be manually deployed first.

If anyone has any thoughts on a solution to the above, then we can try it again.
Actions

Go to original post