Continuous integration

The PLASMA Lab project uses Continuous Integration practice. After an overview on this practice and the tool chain we use, this chapter details the procedure for publishing a new version of PLASMA Lab.



Git is our Version Control System. The Git repository is hosted on and a link to the PLASMA Lab Git can be retrieved by joining the PLASMA Lab Gforge project.


Maven handles project dependencies and build configuration.


Jenkins is an Automated Continuous Integration server. The server is hosted at Jenkins is used to launch automated SNAPSHOT build every night as well as manual release build. Executables are the deployed to Artifactory.

From version 1.4.4 Jenkins is not used in the Continuous Integration process due to uncompatibilities between Jenkins and Maven Artifactory.


Artifactory is an open-source repository manager. Build are stored on it and can be downloaded by PLASMA Lab users. Artifactory is also hosted by INRIA.

Release Procedure (from version 1.4.4)

The procedure is run from the directory fr.inria.plasmalab.root. All links in the procedure are relative to this directory.

1 Prepare the release

Run the script with the new release version and the next snapshot version:

  • The script updates the .bat scripts and the with the new release version and it commit these changes.

  • It then runs the maven release plugin (mvn release:prepare) to update the pom.xml:

    • It updates the pom.xml files to the new release version.
    • It creates a git-tag whose name is the release version.
    • Then it updates again the pom.xml files to the new development version.
    • It commits the changes.
  • Afterwards, the script updates again the .bat scripts and the with the snapshot version.

  • It commits the changes and pushes to the git repository.

2 Build and deploy

Retrieve the tagged release with git checkout release-version and then run the script

  • This runs maven with the assembly, javadoc and deploy plugins (mvn clean package assembly:assembly javadoc:javadoc deploy:deploy):

    • It compiles the .jar artifacts for all the projects (listed in the pom.xml file) .
    • It compiles distribution bundles with the assembly plugin (using the configuration in src/assembly/assembly.xml) in target.
    • It compiles the javadoc in target/site.
    • It deploys the artifacts to
  • It deploys the distribution bundles to Gforge.

  • It deploys the javadoc to Gforge.

Retrieve the head of the repository git checkout master and re-run the script to deploy the snapshot version.

3 Update the documentation

  • Update the content related to the new version.

  • Check links in the documentation that may refer to the old version.

  • Update PLASMA Lab’s version number in

  • Compile with make html and make latexpdf.

  • Run the script with the Gforge user and the new version:

    • It creates a new directory in /home/groups/plasma-lab/htdocs/plasma_lab_doc/.
    • It uploads the html and PDF documentation.
    • It updates the pages index.php and manuel.php with the new version and upload them to Gforge.

4 Update “external” content

This concerns content that is not automatically updated:

  • Update Plasma2Simulink.
  • Update the tutorials if needed.
  • Update the PTA plugin if needed.

5 Update the website

  • Update the version number and the content of the website (if needed). The documentation links are now relative to php files and don’t need to refer to the version.
  • Update the download links.
  • Post a news.
  • Send a mail to the mailing lists ( and

Snapshot Release Procedure (from version 1.4.4)

This releases a new snaphot of the development version:

  • Run the script from fr.inria.plasmalab.root.