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 >>>> >>> >> >>
