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
