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 maven-resource, rather than bypassing that and re-downloading.
Mostly I’m just trying to separate out which problems with geode-examples are helped by your proposal, and which are orthogonal. I assume you just brought up geode-examples as one example of something that consumes Geode. All consumers, including geode-examples, will benefit from having traceable versioning :) > On Apr 27, 2020, at 4:40 PM, Robert Houghton <rhough...@pivotal.io> wrote: > > 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 <onich...@pivotal.io> wrote: > >> 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 <rhough...@pivotal.io> >> wrote: >>> >>> @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 pipeline. >>> >>> >>> On Mon, Apr 27, 2020 at 3:55 PM Owen Nichols <onich...@pivotal.io> >> wrote: >>> >>>> 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 -SNAPSHOT. As far as I can tell, geode-examples develop is >>>> correctly resolving geodeDistribution from >>>> org.apache.geode:apache-geode:1.13.0-SNAPSHOT, and geode-examples >> master is >>>> correctly resolving geodeDistribution from >>>> org.apache.geode:apache-geode:1.12.0 >>>> >>>>> On Apr 27, 2020, at 3:41 PM, Anthony Baker <aba...@pivotal.io> wrote: >>>>> >>>>> @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 >>>> integration-testing-purposes-only I’m not super worried about the ugly >>>> syntax. >>>>> >>>>> >>>>> Anthony >>>>> >>>>> >>>>>> On Apr 27, 2020, at 3:25 PM, Jacob Barrett <jbarr...@pivotal.io> >> wrote: >>>>>> >>>>>> 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 >>>> and predictable downstream builds! >>>>>> >>>>>> With SNAPSHOTS in a repo the repository automatically prunes back old >>>> builds. Do we have any concerns about having a plethora of builds >> filling >>>> up this new pre-release repository? >>>>>> >>>>>> -Jake >>>>>> >>>>>>> On Apr 27, 2020, at 3:21 PM, Robert Houghton <rhough...@pivotal.io> >>>> wrote: >>>>>>> >>>>>>> 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 geode-examples pipeline[2] does not build >> and >>>> test >>>>>>> against the latest artifacts from the develop pipeline. Some work has >>>> been >>>>>>> done already to allow this via "composite" builds for local testing >>>> without >>>>>>> needing to publish Geode to your local Maven repository. >>>>>>> >>>>>>> From a Concourse CI perspective, composite builds are costly due to >> the >>>>>>> rebuild of the upstream artifacts. They allow repeatable builds, but >>>> only >>>>>>> by rebuilding those dependencies. Better would be to point to >> upstream >>>>>>> artifacts as concrete build versions. SNAPSHOT builds can and do roll >>>>>>> (invisibly) as new versions are published. Discrete, numbered builds >> do >>>>>>> not. Downstream consumers can use greedy version specifiers to get >>>> their >>>>>>> current behavior of "latest". >>>>>>> >>>>>>> Gradle: 'org.apache.geode:geode-core:1.13.0+' >>>>>>> Maven: '<groupId>org.apache.geode</group>' >>>>>>> '<artifactId>geode-core</name>' >>>>>>> '<version>[1.13.0,1.14.0)</version>' >>>>>>> >>>>>>> What do you all think? Discuss! >>>>>>> -Robert Houghton >>>>>>> >>>>>>> [1] https://issues.apache.org/jira/browse/GEODE-8016 >>>>>>> [2] >>>>>>> >>>> >> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples >>>>>> >>>>> >>>> >>>> >> >>
