|
Bad thing is, that most of the projects already have final
versions in OSSRH staging. We missed this decision a bit. :( But
this shall be mandatory for next development cycle and all
integrated artifacts that are not released (to central) yet.
Well, maybe we can do another trick when we need to avoid
versions gap here: current x.y.z version -> x.y.z-b01 ->
x.y.z-b02, ... and after x.y.z-bKL passed, update x.y.z tag to
point to it. It's not following https://semver.org/, x.y.z may
still be cached somewhere, but it should work with Maven and GF
integration jobs.
And it should be just an exception for this single release
cycle.
Good news is, that Jenkins jobs don't have persistent workspace
and it always gets latest OSSRH artifacts from staging repo when
old deployments are dropped. I tested this with our projects on
new infra. There are exceptions, but they can delete workspace now
and at the end when all the tests pass before build with final
versions.
But I agree that those updates will be rare now.
Real problem is retention period of OSSRH staging where we don't
have good working solution now.
Tomas
Dne 19.12.18 v 5:37 Bill Shannon
napsal(a):
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
|
