[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[golo-dev] Continuous integration / delivery chain
|
Hi everyone,
We’ve been working with Daniel on a CI/CD chain to properly deliver build artefacts and distributions using the Hudson servers at the Foundation [1].
The goal is to automatically deploy all Maven artefacts to repo.eclipse.org, and distributions to download.eclipse.org. This all needs to be done from the Hudson instances (pushing to repo only works from Maven, and pushing to download is a simple file copy from there). We will still push to Maven Central, but manually through Bintray/jCenter.
We’ve gone through many problems with our instance configuration, but the technical staff is being very helpful. We are now at point where the project can be built and tested, and Maven artefacts can be pushed to repo.eclipse.org.
As I see things:
1. We can have a ‘golo-build’ job that performs the traditional continuous integration duty on the master branch. It can be polling, or triggered from a GitHub hook (Daniel is looking at that option).
2. We can have job to deploy the result of ‘golo-build’ to the Maven repository. We can also have nightly builds, and push the resulting distribution zip to, say, download.eclipse.org/golo/{latest-snapshot,nightly-build}.zip.
3. The question of releases is more interesting. They have Git tags, but dealing with them is not as trivial with Jenkins (oops, sorry, Hudson :-)). A simple option would be to have a parameterized, manual job, where one would enter the corresponding Git tag to build. For instance one would manually trigger the build, and require a deployment of tag `milestone/3.0.0-incubation-M1`. Based on experiments that I did tonight, this seems like a simple yet practical route.
What do you think? BTW committers can work with the Hudson instance, so if you want to help / experiment with the servers feel-free to do so.
[1] https://hudson.eclipse.org/golo/
- Julien
