You're right... As I see it, you are forced to have a different version number for different branches. As such, the build cache may not be effective at all because I imagine the version number is one of the first input considered to determine if the cache can be reused or not.
Disclaimer: I've never used the build-cache plugin (yet, but I plan to) so I may be wrong. Please keep us updated on your plan (I'm interested in the result) Le dim. 24 sept. 2023, 15:14, Ben Tatham <bentat...@nanometrics.ca.invalid> a écrit : > Thanks, Francois. That would have been great for our original problem, but > how I can I leverage that for build cache issues? > > On Sun, Sept 24, 2023, 5:14 a.m. Francois Marot <francois.ma...@gmail.com> > wrote: > > > Just a suggestion: you could use ci-friendly Maven to pass in a version > > depending on the commit Id/sha1 on the command line. Like mvn > > -Drevision=<current git sha1> > > More info: > > https://maven.apache.org/maven-ci-friendly.html > > > > Regards > > > > Le jeu. 21 sept. 2023, 15:49, Ben Tatham <bentat...@nanometrics.ca > > .invalid> > > a écrit : > > > > > Hi, > > > I'm loving the ideas in the maven-build-cache, but I'm running into > some > > > circular build issues that are blocking us from using it at the moment. > > > > > > In many of our projects, we deploy docker images. Ideally, we would > like > > to > > > keep our docker images immutable. To achieve that, we have extra maven > > > plugins that create unique SNAPSHOT version numbers (based on jira > issue > > > ids, git commit hashes, and/our CI build numbers). We do this for > docker > > > image immutability, but also to avoid SNAPSHOT collisions when multiple > > > developers are working at the same time in the same project, but still > be > > > able to deploy the snapshot artifacts for other reasons (temporary test > > > deployments, sharing libraries as snapshots while still in development > > > across projects, etc). > > > > > > But that solution creates unique maven versions in CI for every build, > > > which of course then contradicts using maven-build-cache, since the > > version > > > is always different in CI. > > > > > > To use maven-build-cache, we would just go back to using standard > > -SNAPSHOT > > > builds, but then we have to solve our original issues a different way. > > > > > > (Sadly, AWS ECR only allows setting immutability at the registry > level. I > > > looked at nexus as a docker registry, and it seems to be even higher at > > the > > > whole docker repo level. (We wish we could set immutability of images > > based > > > on the tag - ie allow -SNAPSHOT tags to mutable, but nothing else)) > > > > > > One idea we have is to use a different docker registry for snapshot vs > > > release builds, but since maven properties are evaluated at the > beginning > > > of the maven lifecycle, we cannot change the parameters sent to maven > > > plugins that due to the docker builds once the build starts. Thus, we > > would > > > have to do something outside of maven to detect, eg, if the build is a > > > snapshot and choose a different docker registry there and pass it on > the > > > command line. We would love this to be an all-maven solution. > > > > > > Does anyone else run into similar issues with maven-build-cache? Is > > there > > > some weird way we can ignore the project.version altogether on the > > > maven-build-cache (that seems very odd, for sure though)? Other ideas? > > > > > > Thanks, > > > > > > Ben > > > > > > [image: -] <http://www.nanometrics.ca> > > > [image: -] <https://twitter.com/nanometricsinc> [image: -] > > > < > https://www.linkedin.com/company/nanometrics-seismological-instruments/ > > > > > > [image: > > > -] <https://www.youtube.com/channel/UCwao286g87g7Mqj6qvnLIZw> > > > > > > Ben Tatham > > > Principal Software Developer > > > Nanometrics > > > bentat...@nanometrics.ca > > > > > > -- > > > This message is intended exclusively for the individual or entity to > > which > > > it is addressed. This communication may contain information that is > > > proprietary, privileged, confidential or otherwise legally exempt from > > > disclosure. If you are not the named addressee, or have been > > inadvertently > > > and erroneously referenced in the address line, you are not authorized > to > > > read, print, retain, copy or disseminate this message or any part of > it. > > > If > > > you have received this message in error, please notify the sender > > > immediately by e-mail and delete all copies of the message. > > > > > > > -- > This message is intended exclusively for the individual or entity to which > it is addressed. This communication may contain information that is > proprietary, privileged, confidential or otherwise legally exempt from > disclosure. If you are not the named addressee, or have been inadvertently > and erroneously referenced in the address line, you are not authorized to > read, print, retain, copy or disseminate this message or any part of it. > If > you have received this message in error, please notify the sender > immediately by e-mail and delete all copies of the message. >
