HEllo everyone. I am using pulumi with the new doc...
# pulumi-deployments
m
HEllo everyone. I am using pulumi with the new docker image system. I build and deploy from a github action. My problem is the build does not seem to use the cache even though I configured it according to the blog post :
Copy code
export const image = new Image(
  imageName,
  {
    imageName: concat(repoUrl, '/', imageName, ':', 'latest'),
    build: {
      platform: 'linux/amd64',
      dockerfile: '../Dockerfile',
      context: '..',
      args: {
        BUILDKIT_INLINE_CACHE: '1',
      },
      builderVersion: 'BuilderBuildKit',
      cacheFrom: {
        images: [concat(repoUrl, '/', imageName, ':', 'latest')],
      },
    },
  },
  { dependsOn: [artifactApi, repository] },
);
At every build, every steps of my docker image are built again. Whgen only application code change the building and pushing of layers should be minimal, but rn might gh action atkes north of 6 minutes to complete.
h
@modern-plastic-10593 which registry are you using? (inline caching isn’t supported everywhere)
m
I use gcp artifact registry
h
do you have multiple build targets? e.g., something like “FROM base-image AS build-stage” in your dockerfile?
m
I do have multiple build stage: preparing base, installing deps, building,
If it ever comes to that, would it work if I try caching the local docker directory from GitHub action to GitHub action ?
With the cache from props, pulumi downloads my previous image but does not seem to find cached steps from there
h
there’s a lot that could be going on here, but i suspect what’s happening in your case is your inline cache doesn’t include information about the intermediate build stages, hence why they’re always getting rebuilt.
would it work if I try caching the local docker directory from GitHub action to GitHub action ?
in theory, yes,
--cache-to type=gha
would do the trick, but unfortunately the image resource doesn’t currently expose all of the `--cache-from`/`--cache-to` functionality. this is something we’re going to be working on soon, and if you’re up for it i can keep you posted if you’re interested in beta testing something like this.
m
Yes, thanks a lot. However for the time being what would you recommend ? It will be dificult to build and push outside of pulumi, as the registry address is known in the IaC. If I prebuild the image on the runner would the pulumi build afterward use the local image ?
Or is there a way to push an image built outside, upstream from pulumi ?
h
it depends on your setup, but in a past life i used docker’s build-push-action with github actions to publish images, and then i consumed those tags from my pulumi program. not ideal but something like that is a viable workaround.
m
This is not ideal as again the registry itself depends on the IaC and won't be known before it runs. Do you know I could confirm that artifact registry is the source of my caching problems ?
here’s a lot that could be going on here, but i suspect what’s happening in your case is your inline cache doesn’t include information about the intermediate build stages, hence why they’re always getting rebuilt.
Alternatively, would moving out of a multistage build augment my chances of using a cache ? I do not care about how the dockerfile is set up, i only wish to decrease my time to deploy. Now sitting around 6 minutes, it's not an ideal feedback loop.
And finally, maybe I am missing somehting in my action definition ? For instance, do I need to manually setup anything on top of the pulumi deploy action (docker buildx or other tools ?)
I guess the `registry`type backend is not supported bu the docker Image pulumi component