> 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?
No.
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.
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 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.
Ok.
>
> 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.
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 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.
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
> > 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.
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 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.
I hope I have addressed all of this above.
Thank you,
Liviu
_______________________________________________
embed-cdt-dev mailing list
embed-cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/embed-cdt-dev
