| [jakarta.ee-spec.committee] Questions for tomorrow's Eclipse CI infrastructure agenda item |
In looking into the current use of GPG signing of artifacts as generated for a MicroProfile artifact, and the jakarta.json.bind-api artifact, I’m seeing different digest algorithms being used based on the same maven-gpg-plugin setup. I don’t see the jakarta.json.bind-api ci release build, so I’m not sure what if the differences are coming from there or project local settings.xml or something else. The microprofile-jwt-auth-api artifact is using a SHA1 digest algorithm while the jakarta.json.bind-api artifact is using SHA-256. How to configure this consistently in the release CI environment is one question. Another one is how to generate the GPG signature when not using maven. The current jakartaee-tck build looks to be using ant, so how to access the signing key outside of maven is another question. I see the following information on accessing project specific storage on the download.eclipse.org server: This indicates that once a project has been granted access, the project Jenkins instance will be updated with ssh agent credentials to perform ssh/scp into the project download area. I guess the thing we need to define is a naming convention for both the staging and release EFTL versions of the TCK binary, and the pipeline job fragment to generate the GPG signature of the binaries. Please forward to Fred for discussion tomorrow. |