Ideally, a final artifact would be staged at about the same time as
the Eclipse Release Review is submitted. When the Release Review is
complete ~2 weeks later, the final artifact should be pushed to
Maven Central.
All integration testing before that point should use -bXX version
numbers. Once the integration is proven, the version number can be
updated to the final version and the Release Review submitted.
As Romain says, it should be relatively rare that we need to
re-stage an artifact.
Romain Grecourt wrote on 12/18/18 5:07
PM:
On 12/18/18 4:32 PM, Tomas Kraus wrote:
Hi Romain,
your proposal is nice is nice, but it must be implemented
first. Currently you just come to your office in the morning
trying to move on with your tasks and you get stuck after 1st
attempt to build something. The only way for quick fix is to
restart release job. Our whole team was in this situation on
Monday morning so we decided to fis this using this dirty way.
Otherwise we could just go home.
I wasn't pointing fingers, just exposing this problem to a wide
audience.
Please do not take it personally.
There won't be much projects which have at least job to
rebuild existing tag. I know about a single one from some 50
projects I 'm watching from time to time. And it's there
because I made it today after discussion with Tom. :)
So the other option was to stop working on EE4J projects and
wait for someone to implement jobs to rebuild existing tag. It
would take days.
I understand that you want to move forward but the OSSRH staging
retention is a problem that needs to be fixed.
Let it take days and escalate the issue.
I would also like to do things properly. ...but we have no
promoted builds, no automatic integration jobs, no promoted
repo on OSSRH.. .we just have to manually update version,
build it and file set of PRs witch every single version
update. Just imagine this sample (already discussed JTA API):
They change version. We have JPA API dependency, EclipseLink
dependency, Metro dependencies (not just one) amd all those
things go into GF. So to avoid JTA transitive dependencies
mess in GF, you would like all those projects to share a
single one -> imagine how long it will take to manually
update all of them and do manual reviews and merge, re-release
all those projects again under a new version and finally put
everything into GF. No, you don't want to to this.
That's how Eclipse wants you to do this right ?
IMO this is not a good reason to justify the re-release of Maven
artifacts.
Instead we should expose the impracticality and escalate the
issue.
That's why I think that even existing release rebuild in
staging is still fine when it's done from EE4J_8 branch which
shall contain no significant code changes (new features,
etc.) against last java.net release. I see it as dirty
thing, but still an acceptable tradeoff.
I disagree.
I would rather allow external snapshots than mis-use Maven to that
extent.
The only acceptable changes in EE4J_8 are bug fixes and
modifications to adopt Eclipse environment and requirements
=> those are just pom changes in most cases.
Pom changes can have a significant impact, the dependency tree is
the input for a lot of maven tooling (e.g. maven-bundle-plugin).
But yes, we shall stop doing it at some point to make
integrartion testing more stable.
It would great if you find a way how to restage deleted
artifacts to OSSRH.
This can be done with 2 things:
- zip up the local staging directory used by the
nexus-maven-plugin and archive it as an artifact in the original
Jenkins job.
- create a job that can fetch that zip and use
nexus-maven-plugin:deploy-staged to re-stage the missing
artifacts.
See
https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin#deploy-staged
We can stop doing those bad things after that. But until
this is done, we still need some way to fix this problem
quickly - currently rebuilding it from EE4J_8 head.
I can put my script to rebuild artifact from git tag to wiky,
but it will take 2 weeks for all projects to implement it and
it will generate additional workload.
IMO you are pointing at another process issue.
The projects encapsulation is very strong. Every project gets
their own Jenkins master with their own set of credentials.
This makes sense for some project (glassfish, jersey, metro, etc),
but does not for other much smaller projects (e.g. most API
projects).
There is a lack of common tooling for projects, so far the
release job scripts have been duplicated and flavored many times.
This leads to inconsistency and bad practices to spread all over.
Tomas
Dne 18.12.18 v 23:59 Romain
Grecourt napsal(a):
Folks,
Re-releasing Maven artifacts (or overwrite) has been a common
practice within EE4J projects.
I believe this is mainly due to the release scripts and
Jenkins jobs that make it too easy to re-run the release for a
particular version.
This is a bad Maven practice and should be avoided as much as
possible. We should only do this for very specific use cases
where a version gap is not acceptable.
E.g. an API with a final version has a bug, we can re-release
it while it is still in OSSRH staging.
Releasing a project with a final version where a gap is not
acceptable should be done with extra caution. This means the
integration has been tested before hand very carefully.
If there is a development cycle, intermediate versions (e.g.
1.0-bXX or whatever qualifier fits) can be used, in such case
a version gap is acceptable and maven releases may be done
carelessly.
Re-releasing something already integrated in other projects
can creates issues that are not associated with a git commit.
(i.e the build could start failing without a change).
This is like having the drawbacks of external snapshots
without the benefits.
Note that it also forces purging various Maven caches and
mirrors which can be quite tricky.
There is also the issue of the retention period of OSSRH
staging. Staging repositories will be automatically deleted
after 1 month. This used to be 2 weeks but we got Sonatype to
extend it to 1 month.
This is unfortunately very impractical. IMO this calls for
Eclipse to engage with Sonatype in order to have our own
dedicated nexus gateway, similar to maven.java.net.
The retention period is also why some projects have been
re-released. AFAIK the current workaround is to re-run the
release job with the same version.
If the release is triggered off of a development branch (e.g.
EE4J_8) then the re-released artifacts may have different
content.
Even if triggered from the release tag the artifacts will have
a different fingerprints. While it's not as big of an issue,
this may have bad side effects with things that are re-bundled
(e.g. GlassFish zip distributions).
Instead of rebuilding the Maven artifacts that are missing, we
should provide a way to re-release existing artifacts. E.g.
archive the artifacts on Jenkins and have a way to re-stage
them to OSSRH.
Thanks,
Romain
_______________________________________________
ee4j-build mailing list
ee4j-build@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-build
_______________________________________________
ee4j-build mailing list
ee4j-build@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-build
_______________________________________________
ee4j-build mailing list
ee4j-build@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-build
|
