> I did not spend a lot of time looking at the dyna version plugin and I am not going to ask why as that is just a can of worms.
Its because having the git hash in the version is incredibly useful for users as it allows you to know precisely the git commit that the snapshot is pointing to > However, I notice that the plugin has the option of rewriting the sonatype name I think you mean the version, not the sonatype name here? > plugin keeps track of the builds somewhere outside of the repository (in git perhaps?). So the core point of sbt-dynver is to derive the project's version from git, or in other words the source of truth for your project's version is git and not what is traditionally done (i.e. some hard coded version in the build). A lot of modern projects that are built around git/github/gitlab work this way, especially if you have protected git branches/git tags to ensure you can't mutate the relevant parts of git without approval. > So if you change the configuration to create jars that don't have the build time and push those to the repository you can solve your Infra problem. There appears to be a way to determine the dynatype versions, when they ran, and what the output was called. From this you should be able to map from the dynatype info to both the git source and the repository snapshot. This is correct, as you can see from https://github.com/sbt/sbt-dynver#custom-version-string you have full control of how the final version is determined. However we haven't made a community decision on this. The community actually wants to have these hashes in the version because of its usefulness, it was also this case with Akka so there is more familiarity here. Furthermore there is actual build logic that relies on this versioning (see https://github.com/apache/incubator-pekko-http/blob/main/project/PekkoDependency.scala#L102 ) so changing the way that snapshot versioning is done opens up other can of worms (the idea behind milestone topic was to actually **stop** relying on snapshots at all in builds like this, but that's another discussion) Given this it's more likely that we will create a custom pruning job that recognizes this versioning (INFRA have told us this is also an acceptable solution to the problem). They don't care that much what the versioning is like, they just have an issue with the pruning not happening. On Tue, Aug 8, 2023 at 10:33 AM Claude Warren, Jr <[email protected]> wrote: > I did not spend a lot of time looking at the dyna version plugin and I am > not going to ask why as that is just a can of worms. > However, I notice that the plugin has the option of rewriting the sonatype > name and it appears that the plugin keeps track of the builds somewhere > outside of the repository (in git perhaps?). > So if you change the configuration to create jars that don't have the build > time and push those to the repository you can solve your Infra problem. > There appears to be a way to determine the dynatype versions, when they > ran, and what the output was called. From this you should be able to map > from the dynatype info to both the git source and the repository snapshot. > > > > On Tue, Aug 8, 2023 at 8:38 AM Matthew de Detrich > <[email protected]> wrote: > > > We already know this, INFRA has approached us on this. The extra data > that > > is being added to the build target > > is the git hash so we know which commit the snapshot points to, you can > see > > https://github.com/sbt/sbt-dynver#detail for more information. > > > > On Tue, Aug 8, 2023 at 8:13 AM Claude Warren, Jr > > <[email protected]> wrote: > > > > > Greetings, > > > > > > I recently looked at the snapshot repository for pekko-grpc-plugin and > > > noticed that the build system is adding a unique build number as is > seen > > in > > > [1]. At the time I looked there were 3 different snapshot versions, > > > 0.0.0-87-d8b61dbd-SNAPSHOT/ > > > < > > > > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-grpc-gradle-plugin/0.0.0-87-d8b61dbd-SNAPSHOT/ > > > > > > > 1 Mon Aug 07 13:50:41 UTC 2023 > > > 0.0.0-92-9438c173-SNAPSHOT/ > > > < > > > > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-grpc-gradle-plugin/0.0.0-92-9438c173-SNAPSHOT/ > > > > > > > Mon > > > Aug 07 20:13:31 UTC 2023 > > > 0.0.0-94-0bfb43a6-SNAPSHOT/ > > > < > > > > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-grpc-gradle-plugin/0.0.0-94-0bfb43a6-SNAPSHOT/ > > > > > > > Tue > > > Aug 08 01:31:24 UTC 2023 > > > Now the repository software adds build numbers in the form of > timestamps > > to > > > the build, so if we look in [2] we can see a number of jar files with > > names > > > like pekko-grpc-gradle-plugin-0.0.0-87-d8b61dbd-20230807.134756-1.jar, > > and > > > pekko-grpc-gradle-plugin-0.0.0-87-d8b61dbd-20230807.134756-2.jar. > > > > > > My question is why do we add 87-d8b61dbd > > > < > > > > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-grpc-gradle-plugin/0.0.0-87-d8b61dbd-SNAPSHOT/ > > > >, > > > or 92-9438c173 > > > < > > > > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-grpc-gradle-plugin/0.0.0-92-9438c173-SNAPSHOT/ > > > > > > > to > > > the build target? > > > > > > [1] > > > > > > > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-grpc-gradle-plugin/ > > > [2] > > > > > > > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-grpc-gradle-plugin/0.0.0-87-d8b61dbd-SNAPSHOT/ > > > > > > > > > -- > > > > Matthew de Detrich > > > > *Aiven Deutschland GmbH* > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > *m:* +491603708037 > > > > *w:* aiven.io *e:* [email protected] > > > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* [email protected]
