skaffold cache should be toggle-able

[aablsk]

Describe request or inquiry

Make skaffold caching toggle-able in cloud build pipeline to enable forced rebuilds e.g. in case of base image changes. This could be done by adding another substitution variable to the cloudbuild trigger.

What purpose/environment will this feature serve?

"the Skaffold build cache doesn't account for changes in the base image(s). So the cache restoration should be toggleable: the build cache should only be used for PR builds, and nightly builds should build from scratch."

[palladius]

I like this and I think I have some ideas.

[palladius]

The only way for me to do this (which i've done in the past) is to move the multi steps of the Cloud Build.yaml in a single set -x bash script which will execute everything in series. Then, an ENV variable will togle the calling of action 2 and 4 (gsutil push/pull). This is easy peasy but then the observability of failed bash script will be less visible on Cloud Build side as you'll see ONE step with multiple things which could fail instead of N steps nicely separated at UI side.

PLMK what you want me to do Alex.

[palladius]

Re-reading your reason for having/not having, I'm actually thinking of TWO Cloud Build targets, one with and one without caching. Then we trigger the two Cloud Builds separately. Before doing so, though, we need to solve the double cloud build situation we have now: cloudbuild-mvnw.yaml vs cloudbuild.yaml. I believe we should converge them into a single script.

[aablsk]

@palladius since Cloud Build still does not offer conditional steps (😮), I think having additional Cloud Build triggers which might be run (e.g. nightly) without cache to ensure we ensure that our base images are fresh.

I also agree that having just one cloudbuild.yaml would be desirable, but I would prefer not to blow up the cloudbuild.yaml with the java workaround contained in cloudbuild-mvnw.yaml as this would make it slower and less readable.

[aablsk]

@aablsk TODO: see if mvnw issue is fixed

[aablsk]

have drafted a solution which seems to work, will be merged with tf refactoring

[palladius]

Regarding the conditional steps (two messages ago) let me give you my opinion:

since cloud build doesnt allow great context transportation across steps (env vars) but onky a consistent file system, i fell in love with a mid sized bash with -e option to fail as soon as a step fails. Ckoud build great visualization will dk the rest. Then yiu can do a big bash like

      # code for java
  else
   #code for non java
fi

#common code

While this mught be slightly less readabkenits drier so it gets advantages from enhancements in both flows. I personally had to do so many changes in my project that having two separated cloud build yamls for me would be untenable. Of course if yiu dint add lot of lkogic and env vars over time, and managing thriugh FS is fine, probaboy yiur sokutionnworks better for you.

Il Ven 22 Lug 2022, 11:19 aablsk @.***> ha scritto:

have drafted a solution which seems to work, will be merged with tf refactoring

— Reply to this email directly, view it on GitHub https://github.com/aablsk/bank-of-anthos/issues/14#issuecomment-1192365046, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABANQXHRDT52XRUGPBOXKTVVJRS3ANCNFSM52COKRWA . You are receiving this because you were mentioned.Message ID: @.***>

[aablsk]

I found a solution for the cache toggling that avoids bash which I think is a little more readable in the context of Cloud Build.

When it comes to the example you point out (different cloud builds for maven and others) I'm torn between trying to shoe-horn everything into one cloudbuild.yaml vs putting cloudbuild.yaml on team level instead to allow for teams to have their own configurations. What do you think?