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
|
