On Sat, 17 Jun 2023 at 11:05, Hervé Boutemy <herve.bout...@free.fr> wrote: > > reading the discussion about maintenance branch and "who updates the cache", I > think that: > > 1. maintenance branch is like main branch: with Olivier's nice strategy, you > should build fully. In fact, the few long-lived branches should be built > fully, only the many PR short-lived branches should be built quickly with > cache
When I mean build fully for main branches, I mean only on CI but locally the local cache is used on dev machine. > > 2. "updating" the cache makes you feel that it's like publishing a SNAPSHOT, > ie the last publication wins over previous ones. With cache, any publication > is just an addition of new content, indexed by input checksums. Then we don't > really care about who is the first discovering a new input checksum, then > filling the output cache for that new input checksum. > > Really nice feedback on build cache extension in real life! > > Thanks a lot to the contributor to this great feature > > Regards, > > Hervé > > Le mardi 13 juin 2023, 07:11:50 CEST Olivier Lamy a écrit : > > On Mon, 12 Jun 2023 at 21:38, Benjamin Marwell <bmarw...@gmail.com> wrote: > > > Am Mo., 12. Juni 2023 um 12:08 Uhr schrieb Olivier Lamy > <ol...@apache.org>: > > > > On Mon, 12 Jun 2023 at 18:53, Benjamin Marwell <bmarw...@apache.org> > wrote: > > > > > Hello everyone! > > > > > > > > > > First of all thank you everyone working on the build cache plugin! It > > > > > is amazing! > > > > > > > > > > At least some of the following questions seem to be of interest to > > > > > most users and might end up on the documentation, So here's a few > > > > > things which came to my mind. > > > > > > > > > > 1.) Considering I always require PRs in my projects, would setting > > > > > -Dmaven.build.cache.remote.save.enabled=true be a sensible thing only > > > > > for the main branch? > > > > > > > > Personally, I would have the main branch always have a full build > > > > without caching to be sure everything works fine but use cache only > > > > for branches/PR :) > > > > That's what we will do at Jetty project. > > > > The build for 12 branch is around 50 minutes with the cache it goes > > > > down to 8/9 minutes (only because something is always rebuilt and > > > > retrigger a few small modules) > > > > The idea is to reduce development/check of PR and use some incremental > > > > build while the main is always fully build especially when the build > > > > has few jdks as target. > > > > But here it's up to you :) > > > > > > I can see your point, but who is updating the remote cache then? > > > > every PR potentially updates the cache. depending on changes per PR > > some module cache will be shared or not with other PRs. > > We (Jetty project) have decided to not have any publicity open remote > > cache setup per default as we do not have the infra for this (but CI > > use a private one) > > but in a company context or if you have the infra for this it might be > > a better option. > > > > > > > 2.) Can I maybe have the branch name included in a path to a remote? > > > > > This way I could have a different cache for maintenance branches. Just > > > > > include the branch name into -Dmaven.build.cache.remote.url? > > > > > > > > why would need that? > > > > if your branch has different sources (java, pom, etc..) the calculated > > > > hash will be different so the hash key will be simply different no > > > > need to configure a cache URL differently (well except if you want to > > > > clean up caches per branch) > > > > > > It depends on what you might be trying to do. For projects with new > > > major versions and some > > > big refactoring done in the past, this did sound sensible to me. > > > What is the cache worth if there's 0% hit on the maintenance branch? > > > > hit ratio will depend on the changes you do. > > parent pom change -> everything will be rebuilt > > single java source in a module: only this module and dependant will be > > rebuilt. Finally, there is no single rule on how to use/configure the > > cache, the usage depends on how a team is working, what sort of change they > > often have, etc... > > first, have your build working (if it's complicated one you may have > > some extra configuration to add) > > > > > > > 3.) Can I somehow use option 1 & 2 to make caches available for > > > > > colleagues without making them manually configure the remote URL for > > > > > each branch they are working on? > > > > > > > > cache will be used by colleagues' build as long as a module have the > > > > same calculated hash any local differences will have a different > > > > calculated hash > > > > > > Same as above: > > > What about devs working on a maintenance branch when main has seen big > > > refactoring? > > > > > > > > 4.) The docs say there's also XX and XXMM algorithms, but it doesn't > > > > > say WHEN to use them (only that they may leverage performance). Are > > > > > there some example cases or does someone already have some experience > > > > > we could benefit from? > > > > > > > > I have yet to see huge differences. > > > > currently with a build already down from 50 minutes to 8/9 minutes not > > > > sure this was my primary goal > > > > So I can't really tell :) > > > > > > Well, it is listed under "performance tuning", so I concluded it might > > > make a difference. > > > Will probably go for XX (because it is mentioned as performance tuning > > > without any drawbacks) > > > > > > and switch to Metro once it is there. > > > > > > > > 5.) The section "filtering out artifacts" might want to give a size of > > > > > artifacts which should be regarded as too large, depending on the > > > > > environment probably. > > > > > > > > definitely depends on your environment. > > > > > > Yup. > > > I might use different settings in a corporate environment, my thought. > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
