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

> 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?

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.

> 	• 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.

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

What are the PR builds?

> 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.

> > - 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.

> > 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.

> 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?

> 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.

Thank you,


Back to the top