Re: [embed-cdt-dev] Prepare for first incubation release

[Liviu Ionescu <ilg@xxxxxxxxxx>]

> 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 download.eclipse.org, with a subdirectory per branch built: https://download.eclipse.org/embed-cdt/nightly/ (e.g. develop branch's p2 repo is https://download.eclipse.org/embed-cdt/nightly/develop/ with zipped version of the repo in ilg.gnumcueclipse.repository.zip)

Ok

> 	• I updated the shield and link in the README.md 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 https://download.eclipse.org/embed-cdt/releases/experimental/ (to be used during development)
> 
> This job is https://ci.eclipse.org/embed-cdt/job/nightly/job/develop/ and the publish location is https://download.eclipse.org/embed-cdt/nightly/develop/

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 https://projects.eclipse.org/projects/iot.embed-cdt

Makes sense.

> > - a second one to build the develop branch and publish at https://download.eclipse.org/embed-cdt/releases/test/ (to be used as pre-releases)
> 
> For this I recommend either building from the master branch, which will be automatically published to https://download.eclipse.org/embed-cdt/nightly/master 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 https://download.eclipse.org/embed-cdt/releases/latest/ and https://download.eclipse.org/embed-cdt/releases/x.y.z/
> 
> 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 https://www.eclipse.org/downloads/ 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 https://github.com/gnu-mcu-eclipse/org.eclipse.epp.packages 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,

Liviu