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

[Liviu Ionescu <ilg@xxxxxxxxxx>]

> On 18 Apr 2020, at 13:52, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
> 
> 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.

I merged it. 'builds' is slightly better than 'nightly', but, from a user point of view, I'm not sure it is very appropriate.

and having the folders based on the branch name might be easy to understand by developers, but from a user perspective, I think that the previous 'experimental' and 'test' names were easier to understand.

perhaps in a subsequent iteration we can also consider such names.

for now it is ok, I guess with some user triggered jobs we can copy the result to such folders.

if using 'releases/test' and 'releases/experimental' is not appropriate, perhaps we can find a better structure based on these (or similar) names.

for you to better understand how I used these pre-release update sites, the experimental one was mainly for my own use, to run tests on various machine.

the 'test' url was intended for other users, generally those who reported bugs, to give them a way to test the result, before making the final release. but was also used by 'brave' users, who wanted to have bleeding edge plug-ins.

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

we'll probably have a developer page in the new web.

> The build will run automatically on each commit - and can be scheduled too. To run it manually visit the job and press Build Now.

ok

> PR = Pull Requests. Have you ever had PR builds? I assume you did with Travis.

ah, yes, but I did not know that we already can trigger Jenkins jobs from GitHub. nice.

> 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
> 
> You can parameterize a build to do that, so that you are prompted for the x.y.z if that is preferred over editing the script each time. The parameters are converted to environment variables. I added a simple example for you here that you can press Build with parameters on. I have also made that job triggerable remotely so you can do a GET on https://ci.eclipse.org/embed-cdt/job/simple-param-job/buildWithParameters?token=TOKEN&VERSION_NUMBER=3.4.5 (replacing TOKEN with the token in the build job config in the Build Triggers section)

I'll experiment with this, but it'll take me a few days to get to it.


> Should we transfer the https://github.com/gnu-mcu-eclipse/org.eclipse.epp.packages project to the new organisation too?
> 
> Yes - if you want to publish the package on download.eclipse.org.

eventually. for now I'm inclined to also keep the packages published as GitHub releases.


regards,

Liviu