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