I have no current plans on backporting, though it might make the continued
Concourse testing of those branches easier.
There is a PR about this available:
https://github.com/apache/geode/pull/5057
On Thu, Apr 30, 2020 at 9:25 PM Owen Nichols wrote:
> It sounds like the only impact is that downs
It sounds like the only impact is that downstream projects that consume
-SNAPSHOT builds will need to make one small change to their maven config;
downstream projects that consume release versions will be unaffected. So just
let us know when to make that change.
Anytime soon after support/1.13
I don't read any strong negatives to this change. I would like to start
polishing a PR on this work, unless anyone has strong opposing feelings.
Does anyone feel that this change requires a VOTE?
On Tue, Apr 28, 2020 at 10:36 AM Jacob Barrett wrote:
> Probably for a separate discussion but I wou
Probably for a separate discussion but I would opt for a future where the
release manager validates and signs a specific build from produced by the CI.
This takes a lot of error away in the what the release manager currently does,
which has resulted in incorrect artifacts being voted on.
In th
Note that I’m asking about building on my local system. Will the version
listed in gradle.properties use the full 1.13.0-build.123 syntax? How would it
get bumped?
Would a release manager end up using just 1.13.0? Hoping for yes :-)
Anthony
> On Apr 28, 2020, at 9:24 AM, Robert Houghton wr
@anthony
/develop would say 1.13.0-build.230 (as of this morning).
Once cut, /release/1.13 would say 1.13.0-build.231, and /develop would
switch to 1.14.0-build.1.
gfsh would return that full value. That is the artifact version.
On Mon, Apr 27, 2020 at 4:38 PM Anthony Baker wrote:
> If I build
hat they might
> have
> > done to remedy it?
> >
> > From: Robert Houghton
> > Sent: Monday, April 27, 2020 4:31 PM
> > To: dev@geode.apache.org
> > Subject: Re: [DISCUSS] Publish Builds, not Snapshots
> >
> >
4:31 PM
> To: dev@geode.apache.org
> Subject: Re: [DISCUSS] Publish Builds, not Snapshots
>
> The artifact would change from "1.13.0-SNAPSHOT" to "1.13.0-build.123".
>
> The number after the "build" slug is auto-incremented by our CI system
> anyway, as the
Not sure that’s true. Internally maven snapshot repos are versioned, and the
maven-resource is able to download any desired version still on the server,
even if maven itself doesn’t expose that capability. You just need to ensure
your job uses the version put into the local maven cache by the
But the "maven-resource" type is still non-repeatable for SNAPSHOTs.
Resource pinning will not work, and identifying the actual GEODE build
causing the failure won't work.
On Mon, Apr 27, 2020 at 4:39 PM Owen Nichols wrote:
> That sounds like a problem with geode-examples regardless of whether w
That sounds like a problem with geode-examples regardless of whether we use
-SNAPSHOT or -build.123 … we should replace the 24hr trigger with a
maven-resource trigger (nulldriver, linkyard, or similar)
> On Apr 27, 2020, at 4:34 PM, Robert Houghton wrote:
>
> @Owen: What geode-examples is doin
If I build the /develop branch and run `gfsh version` what will it print?
If I build the soon-to-be /release/1.13 branch and run `gfsh version` what will
it print?
Anthony
On 4/27/20, 4:32 PM, "Robert Houghton" wrote:
The artifact would change from "1.13.0-SNAPSHOT" to "1.13.0-build.123
: Re: [DISCUSS] Publish Builds, not Snapshots
The artifact would change from "1.13.0-SNAPSHOT" to "1.13.0-build.123".
The number after the "build" slug is auto-incremented by our CI system
anyway, as the "geode-build-version" semver resource. We are actually
@Owen: What geode-examples is doing, is a perfect case study of the wrong
behaviors predicated on 'SNAPSHOT' with Concourse.
Concourse CI is built on repeatable builds with defined input. The current
CI for examples is using a 24hr trigger because it has no valid dependency
on the Geode develop pi
The artifact would change from "1.13.0-SNAPSHOT" to "1.13.0-build.123".
The number after the "build" slug is auto-incremented by our CI system
anyway, as the "geode-build-version" semver resource. We are actually doing
*more* work in Gradle to truncate that number from the current "SNAPSHOT"
value
Sounds good to me, based on the repeatability argument. Will the build number
output by gfsh version --full match the maven artifact spec?
I am unclear what geode-examples has to do with this. Aside from
repeatability, there is no reason geode-examples should be having any problem
with -SNAPS
@Robert, can you show some examples of what the build number would be under
this proposal? Does 1.13.0-SNAPSHOT become 1.13.0.N where N increments every
build?
Seems reasonable. Since the consumers of pre-release artifacts are either a)
this project or b) close related projects for integratio
It is unfortunate that the Maven/Gradle community hasn’t addressed this glaring
issue with SNAPSHOT for decades now (well maybe not decades but certainly
decade). It is also unfortunate that the Maven version coordinate is ugly.
Aside from that I am totally onboard. Yay for reproducible builds a
Hello to the community,
tl;dr - Lets publish builds, not snapshots, for repeatable CI builds, as
GEODE-8016[1]. Communicate desired artifact version via the existing
'UpdatePassingTokens' job.
I have been working on the Geode build and CI systems for a long time, and
it has irked me that the geod
19 matches
Mail list logo
