Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
EclipseSCADA/Release/Perform
Contents
Preface
Common stuff
All release builds are performed using the "aggregator-release" project -> https://hudson.eclipse.org/eclipsescada/job/aggregator-release/
Related pages:
This document uses "bash" shell commands and assumes your are running a Linux system with the following tools installed:
- Git
- Java 1.8
- Maven
Naming
Release Branch: 0.1.x-release
Tags (Release): R0.1.0
Tags (Milestone): S0.1.0.M1
Process
For each release cycle there will be a new branch: e.g. 0.1.x-release. On this branch we will force the version qualifiers using our own maven plugin. Qualifiers are generated using the tycho jgit buildtimestamp plugin, but using a custom plugin (org.eclipse.scada.releng:build-helper).
Development goes on in the "master" branch. Changes are merged from the master branch to the release branch. The branch committing the generated qualifiers will be revered (using git revert) and then the master branch will be merged in. This means also that the last commit on the release branch MUST BE the commit of the generated qualifiers.
After the release, so for service releases, the master branch will NOT be merged to the release branch. Changes will me manually merged to the release branch, so the automated merging will not take place.
The generated qualifiers will be committed, tagged and pushed to the release branch after a local build.
The Hudson instance will be used to compile and sign the release branch. It will create a local "staging" directory which will receive the content that will go to download.eclipse.org.
The build is checked and then promoted to the download area.
Check out releng tools
You will need to check out the releng shell scripts:
git clone git://git.eclipse.org/gitroot/eclipsescada/org.eclipse.scada.releng
The shell scripts are under "performRelease". All following commands assume you are in that directory.
You will need to set the environment variable ECLIPSE_COMMITTER to the name of your gerrit account:
export ECLIPSE_COMMITTER=<account>
Change into the project directory:
cd org.eclipse.scada.releng/performRelease/
Prepare new release branch
This means branches: 0.1, 0.2, … Milesone releases and service releases will go to the same branch
Create a new branch for each release cycle: e.g. 0.1.x-release
Edit the file "profile" and update the branch name (version, branch).
Execute:
./createBranch
Check the output in the "workspace" directory.
Push the branch to gerrit:
./pushBranch
Changes on the master must be merged to the release branch during the release cycle. New features that should not be included in the release must go to separate feature branches. After the final release is performed they may be merged on the master.
If it turns out that merging on the release branch is to cumbersome we will make branches for every release tag in order to prevent merge issues.
Update release branch
After the release branch has been created and must by updated at some point from the master branch.
./checkoutBranch ./mergeFromMaster
Apply version
./applyVersion ./createTag
Building
Check the output in the "workspace" directory.
Build locally (milestone):
./buildLocally
Build locally (release):
./buildLocally -r
Wait and check the output in /tmp/my-download-test
If everything looks good push the commit and tag.
Push release commit and tag
Push the forces qualifiers and the tag:
./pushTag
Check https://git.eclipse.org/c if the changes made it to gerrit.
Perform build
Perform the build on the Eclipse SCADA Hudson instance
- Job: https://hudson.eclipse.org/eclipsescada/job/org.eclipse.scada.releng.superParent/
- Wait for the job to complete!
- Job: https://hudson.eclipse.org/eclipsescada/job/aggregator-release/
The result is in the directory "staging" under the workspace of the project "aggregator-release".
Test
The usual…
Promote
- Run the CI job -> https://hudson.eclipse.org/eclipsescada/job/promote-release/
This job will copy (using local rsync) the output of the build to the download area and afterwards build the composite repositories for "/updates".
MSI
Creating the MSI files is a task which requires a windows build slave. Therefore we do have a job at the global hudson instance. However the windows slave cannot push files to the download area. So we do need a second job that promotes the MSI files from the output of the job, running on the global hudson, to the download area.
This whole process is performed after the main build is done and everything is already at the download area.
Build the MSI installer
Start the MSI installer job from the main Hudson instance: https://hudson.eclipse.org/shared/job/EclipseSCADA-Installer-Windows
You will need to specify the version, buildId and versionSuffix (e.g. -M3).
Promote the MSI files
Run the promote-msi-release job from the HIPP instance: https://hudson.eclipse.org/eclipsescada/job/promote-msi-release/
Use the same version, buildId and versionSuffix as you did for the build job on the global hudson instance.
However this would require a post-build-action, after the artifacts have been gathered, which calls an URL with the parameters of the current build. This seems not to be possible at the moment.
Publish to Maven Central
Update the properties file in: "publishToCentral" in the "releng" repository.
See: https://hudson.eclipse.org/eclipsescada/job/00-publishToCentral/
The one liner test
rm -Rf workspace && ./checkoutBranch && ./mergeFromMaster && ./applyVersion && ./createTag && ./buildLocally
Legal Stuff
This is required for major releases (not for milestone or maintenance releases).
- https://www.eclipse.org/projects/ip_log.php?projectid=iot.eclipsescada
- https://eclipse.org/projects/tools/downloads.php?id=iot.eclipsescada
Update Web-Page
Do not forget to update the EclipseSCADA/Release/Webpage!