Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [embed-cdt-dev] Prepare for first incubation release

Jonah Graham
Kichwa Coders

On Sat, 18 Apr 2020 at 04:02, Liviu Ionescu <ilg@xxxxxxxxxx> wrote:

> On 18 Apr 2020, at 04:41, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
> I have done the first part of Jenkins build, sign and deploy.

Great, thank you!

> See commit d2fde9970.
> Summary is:
>       • CI job is a multi-branch pipeline, as the develop branch is merged to other branches they will automatically start building because of the presence of nightly.Jenkinsfile.

As the name implies, this is a cron job that is executed in each night?

No. It is a continuous integration job. I did PR#378 for you to rename the nightly -> builds. Please feel free to request a different name.

If there are no new commits, doest it still trigger a new build?


Given that there are only a few commits from now and then, daily (actually nightly) builds might be a waste of resources.


>       • Builds are signed and published to a nightly build location on, with a subdirectory per branch built: (e.g. develop branch's p2 repo is with zipped version of the repo in


>       • I updated the shield and link in the with the above URLs.

Ok. The README file will require further updates when the URLs are final.

>       • The EF will soon have a web app to manage the download server, see Bug 546528. In the meantime we can do simple cp commands wrapped in a Jenkins job.

I'll investigate how to do this.

There is help on Eclipse wiki - but as that documentation can be a bit long, I added a quick start for your use case to the PR#378 - feel free to relocate that help elsewhere.

>       • I can look into remote triggering of the job later. I have minimal experience doing this.

For Travis I use a small script with a curl POST, it is just a double click away from my mac.

But pushing a button in the Jenkins UI would be fine too.

The build will run automatically on each commit - and can be scheduled too. To run it manually visit the job and press Build Now.

>       • If/when we want Jenkins to do PR builds I can enable that too

What are the PR builds?

PR = Pull Requests. Have you ever had PR builds? I assume you did with Travis.

> The above maps to your original request as follows:
> > So, at first sight, we need three jobs:
> We have a single job to build all the branches.
> > - one to build the develop branch and publish at (to be used during development)
> This job is and the publish location is

Ok, this is a bit different, but I guess it can be accommodated.


> Note - we can't call anything that is not a release a release. So it makes our explaining easier to not have releases in the URL either. A release is something that is listed as a release on the PMI

Makes sense.

> > - a second one to build the develop branch and publish at (to be used as pre-releases)
> For this I recommend either building from the master branch, which will be automatically published to or a simple copy using the soon to arrive web interface from nightly to pre-release name

So nightly/master will be it.

Ok. (Unless you accept the PR#378 or provide another name)

> > - a third one for the final release, with a build of the master branch and two publishes, at and
> A simple copy using the soon to arrive web interface from nightly to pre-release name

You mean a new jenkins job. we have to further investigate. actually 2 copy operations. the one to releases/latest is probably clear, the second one to a versioned folder is a bit trickier, to pass the version.

What I am recommending is (following steps I put in PR#378) is to do:

${SSH} cp -rpvf ${DOWNLOAD_ROOT}/nightly/master ${DOWNLOAD_ROOT}/releases/latest
${SSH} cp -rpvf ${DOWNLOAD_ROOT}/nightly/master ${DOWNLOAD_ROOT}/releases/x.y.z

You can parameterize a build to do that, so that you are prompted for the x.y.z if that is preferred over editing the script each time. The parameters are converted to environment variables. I added a simple example for you here that you can press Build with parameters on. I have also made that job triggerable remotely so you can do a GET on (replacing TOKEN with the token in the build job config in the Build Triggers section)

> > In a second step, when hopefully I'll have more experience with Jenkins, we'll consider how to build the EPP packages, and what are the requirements to later align with the simrel rules.
> As for EPP - I hope that we can just add it as a new project on the existing EPP at Eclipse so that it can be managed as part of the Eclipse Release Train and be available on and in Eclipse Installer.

That would be fine, but it'll probably require some more work.

Certainly will.

> In the meantime it may be easiest to just continue managing as is currently in place, rather than do two migrations.

Should we transfer the project to the new organisation too?

Yes - if you want to publish the package on

> Let me know if you see something awry.

Seems fine, I need to understand how to trigger the builds on demand, and how to pass params to them.

I hope I have addressed all of this above.

Thank you,


embed-cdt-dev mailing list
To unsubscribe from this list, visit

Back to the top