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
I have done the first part of Jenkins build, sign and deploy.

See commit d2fde9970. 

Summary is:

  1. 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.
  2. 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)
  3. I updated the shield and link in the README.md with the above URLs.
  4. 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.
  5. I can look into remote triggering of the job later. I have minimal experience doing this.
  6. If/when we want Jenkins to do PR builds I can enable that too 
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)


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

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

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

> 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. In the meantime it may be easiest to just continue managing as is currently in place, rather than do two migrations.

Let me know if you see something awry.

Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Tue, 7 Apr 2020 at 19:01, Liviu Ionescu <ilg@xxxxxxxxxx> wrote:


> On 7 Apr 2020, at 23:32, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
>
> In Jenkins you create a job to do the copying. It can be a freestyle job that does the copy from somewhere.
>
> At some point the project needs a jenkins instance so that artifacts can be signed too.
>
> I am very happy to take on the Jenkins setup work so that signed builds are published nightly and using what I have applied to other projects to this project for handling the releng. Just let me know.

Great, thank you.

The initial idea to keep the archive of zips on GitHub and the p2 site(s) at Eclipse is not cast in stone. The reasons I prefer GitHub is that I'm familiar with it and so far it proved quite reliable, but if you can help me with Jenkins and we can automate everything (build & publish), we can start with this, and decide later if it is necessary to keep a backup of the zips as GitHub releases.

According to https://wiki.eclipse.org/CBI, apparently the first step is to create a bugzilla ticket and ask for an account there, right? (the documentation, as in many other cases, is rich in details but is very confusing for first time readers).

Then, in the initial step, I suggest we consider only the jobs to build and publish the p2 repo and the zips.

So, at first sight, we need three jobs:

- one to build the develop branch and publish at https://download.eclipse.org/embed-cdt/releases/experimental/ (to be used during development)
- 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)
- 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/

For Travis, in addition to the common jobs triggered by commits, I found very convenient to trigger the jobs manually, by posting a JSON with curl, and in that JSON it is possible to fully define the job.

I don't know how Jenkins works, but if something similar is available, we can add some simple scripts to the project and invoke them as needed.


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.


What do you think?


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

Back to the top