[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jakarta.ee-spec.committee] Ideas for downloads area and binary signing/promotion
|
Here is what we already have in-hand and completed with regards to the download and setup. This can be adjusted. I'm happy to work with Mikael on the infra team on whatever changes we want. Our status is that after several weeks of not getting a Jenkins instance for the specification committee, once I finally got his time I pushed forward as we don't have a lot of time.
Our created Jenkins instance is here:
- https://ci.eclipse.org/jakartaee-spec-committee
Our agreed website layout for each spec and version on the jakarta.ee website is this:
- https://jakarta.ee/spec/servlet/3.4/<stuff>
Based on that I gave Mikael direction to enable us to have the same structure for the download area. As a result he created this base directory for us and gave the `jakartaee-spec-committee` Jenkins instance write access:
- https://download.eclipse.org/jakartaee/
The above is what we have completed.
PROPOSAL
The proposal from here would be create a directory structure under https://download.eclipse.org/jakartaee/ that matches the agreed https://jakarta.ee website structure. For example:
- https://jakarta.ee/spec/servlet/3.4/<stuff>
- https://download.eclipse.org/jakartaee/servlet/3.4/<stuff>
- https://jakarta.ee/spec/messaging/2.1/<stuff>
- https://download.eclipse.org/jakartaee/messaging/2.1/<stuff>
DAY ONE ACCEPTABLE IMPL
The first implementation of this would be a parameterized Jenkins job that took the 1) spec name, 2) version and 3) staged TCK zip URL and promoted it into the above directory, signed. This would give us:
- https://download.eclipse.org/jakartaee/messaging/2.1/messaging-tck-2.1.zip
- https://download.eclipse.org/jakartaee/messaging/2.1/messaging-tck-2.1.zip.asc
- https://download.eclipse.org/jakartaee/messaging/2.1/messaging-tck-2.1.zip.sha1
The advantage is we don't really need to coordinate with projects right now. We just paste in their staged TCK URL wherever it happens to point.
POST JAKARTA EE 8 IMPL
After we get through Jakarta EE 8 and we have the opportunity to give some clearer direction, we ask for 1) spec name, 2) version and 3) staged directory to promote that must contain a TCK zip at minimum. We would sign and promote everything in the directory, so specifications should put anything in there they don't want available in their download directory.
A specification project might give us this directory to promote:
- https://<someplace>/staging/servlet-5.2/servlet-tck-5.2.zip
- https://<someplace>/staging/servlet-5.2/servlet-examples.zip
- https://<someplace>/staging/servlet-5.2/whitepaper.pdf
- https://<someplace>/staging/servlet-5.2/somedir/anyfilename.zip
We would promote all their materials when we vote on their "5.2" release, as follows:
- https://download.eclipse.org/jakartaee/servlet/5.2/servlet-tck-5.2.zip
- https://download.eclipse.org/jakartaee/servlet/5.2/servlet-examples.zip
- https://download.eclipse.org/jakartaee/servlet/5.2/whitepaper.pdf
- https://download.eclipse.org/jakartaee/servlet/5.2/somedir/anyfilename.zip
ADVANTAGES
We are being asked as a specification committee to approve versions, so there is simplicity in having both the website and download directories think in terms of versions, allowing projects to have freedom on what goes underneath the version.
Our contract with projects is then basically: give us what you want promoted for your version 5.2 and we'll put those materials here and here:
- https://jakarta.ee/spec/servlet/5.2/
- https://download.eclipse.org/jakartaee/servlet/5.2/
Anything they want directly in https://jakarta.ee/spec/servlet/5.2/ would be in the Github PRs commits. Anything they want promoted to https://download.eclipse.org/jakartaee/servlet/5.2/ would be under a single link they give us.
Over time we can change where we put things with no impact to the promotion logic. Today we want specs in the PR commit, which results in them being on https://jakarta.ee/spec/servlet/5.2/ unsigned by us. In the future, we might decide they should be signed and we prefer projects to put it in their download directory resulting in this:
- https://download.eclipse.org/jakartaee/servlet/5.2/servlet-5.2.pdf
- https://download.eclipse.org/jakartaee/servlet/5.2/servlet-5.2.pdf.asc
- https://download.eclipse.org/jakartaee/servlet/5.2/servlet-5.2.pdf.sha1
To make this happen we wouldn't need to make any changes to our Jenkins jobs. Specifications would just arrange their materials differently upon our request.
NIGHTLY NEEDS
If we wanted to have a nightly directory where projects could have things promoted, we could probably accomplish that with a Jenkins job pretty easily. It could be as simple as "tell us where you'll be putting files and we'll copy that dir nightly." That could enable a directory like this:
- https://download.eclipse.org/jakartaee/servlet/nightly/servlet-5.3-SNAPSHOT.pdf
- https://download.eclipse.org/jakartaee/servlet/nightly/servlet-5.3-SNAPSHOT.pdf
We could even delete the prior files before copying the new files in, which would keep it clean.
Alternatively, we can work with Eclipse infra to give specification projects direct access to their "nightly" directory:
- https://download.eclipse.org/jakartaee/servlet/nightly/<servlet-specification-project-writable>
This is a nice-to-have if we can get it.
-David
