Skip to main content

[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



Back to the top