Jump to: navigation, search

Sequoyah/Helios build guide

Helios build guide

Well, how is Helios generated?
The Helios build is a process that runs automatically whenever they detect that project's build files have changed on CVS. Then the repositories go through some aggregation process and a new Helios product is available! (Yes, this is a VERY SIMPLE explanation. If you want to know more details, talk to the guys from the cross-project-dev mailing list, that they will surely know how to guide you correctly! ;-)

What do I have to do?

  • You need a workspace with the Helios build files, so browse the CVS repository below and checkout the correct module:
Host: dev.eclipse.org
CVS repository path: /cvsroot/callisto
  • Under the HEAD node, checkout the org.eclipse.helios.build project
  • You should edit the build files related to the project you want to add to the next Helios build
  • If you have commit rights on the callisto project, you can commit your changes.

ATTENTION: be aware that a commit on these files will trigger a new build and this has consequences for everybody!

  • If you don't have commit rights, then create a patch and add it to a bug. If you still don't have a bug for Helios release, then open one against the "community" product and the "cross-project" component. Attach the patch file to this bug and wait for replies from the cross-project mailing list.

What should I change in the build file?

Below is a very simple example of a build file:

 <?xml version="1.0" encoding="ASCII"?>
 <build:Contribution xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:build="http://www.eclipse.org/amalgam/2008/build" label="abc">
  <contacts name="Contact1 Name" email="contact1@email"/>
  <contacts name="Contact2 Name" email="contact2@email"/>
  <features id="feature1" version="1.0.0.qualifier" repo="//@repositories.0">
    <category href="helios.build#//@categories.5"/>
  </features>
  <features id="feature2" version="1.0.0.qualifier" repo="//@repositories.0">
    <category href="helios.build#//@categories.5"/>
  </features>
  <repositories location="http://your.repo/location" label="repo label to be found"/>
 </build:Contribution>

Ideally, you would only have to change the version parameter of the features tags in these files. Maybe you have to add or remove some features (don't forget to take a look at this bug for some guidance on the matter of removing things from the aggregation repository).
If you have your features in more than one repository, you just have to add another <repositories> tag and change the parameter repo="//@repositories.#", increasing the number (#) accordingly.

How do I know if it works?

Here you have a full list of the latest builds that failed and that succeeded.

USEFUL TIP: It is a VERY NICE PRACTICE to put descriptive and meaningful comments on your commits. Take a look at this build: the comment for the Sequoyah project already explains what was done. You have to go to the details on the third comment to know what it is. ;-)