https://pulumi.com logo
#general
Title
# general
q

quick-fall-21011

01/17/2022, 12:36 AM
I have searched for a solution to this but getting nowhere. Can someone please advise how to build a docker image in Pulumi so that it doesn't push a new one to the registry when there were no changes. In my case, that happens on each
pulumi up
which then also triggers a kubernetes deployment. All highly inefficient. Here's how I build:
Copy code
//context "../../../src/AppABC"
        var imageName = Output.Format($"{_registryServer}/{imageBaseName}");
        var image = new Image($"{appName}-image", new ImageArgs
        {
            Build = new DockerBuild { Context = context },
            ImageName = imageName,
            Registry = new ImageRegistry
            {
                Server = _registryServer,
                Username = _registryUsername,
                Password = _registryPassword
            },
        });
If there's another way to optimise the workflow that would be an option too.
My deployment takes the output of the image
new image, results in new deployment
Don't believe this is of any consequence but it's running in circle-ci
Running the docker build locally repeatedly the same sha is calculated
Copy code
xxxx> docker build . --tag test
[+] Building 0.4s (17/17) FINISHED
 => [internal] load build definition from Dockerfile                                            
 => => transferring dockerfile: 32B                                                             
 => [internal] load .dockerignore                                                               
 => => transferring context: 2B                                                                 
 => [internal] load metadata for <http://mcr.microsoft.com/dotnet/sdk:6.0|mcr.microsoft.com/dotnet/sdk:6.0>                               
 => [internal] load metadata for <http://mcr.microsoft.com/dotnet/aspnet:6.0|mcr.microsoft.com/dotnet/aspnet:6.0>                            
 => [build 1/6] FROM <http://mcr.microsoft.com/dotnet/sdk:6.0|mcr.microsoft.com/dotnet/sdk:6.0>                                           
 => [internal] load build context                                                               
 => => transferring context: 11.95kB                                                            
 => [base 1/2] FROM <http://mcr.microsoft.com/dotnet/aspnet:6.0|mcr.microsoft.com/dotnet/aspnet:6.0>                                         
 => CACHED [base 2/2] WORKDIR /app                                                              
 => CACHED [final 1/2] WORKDIR /app                                                             
 => CACHED [build 2/6] WORKDIR /src                                                             
 => CACHED [build 3/6] COPY [xxx.csproj, xxx/]                                                  
 => CACHED [build 4/6] RUN dotnet restore "xxx/xxx.csproj"                                      
 => CACHED [build 5/6] COPY . .                                                                 
 => CACHED [build 6/6] RUN dotnet build "xxx.csproj" -c Release -o /app/build                   
 => CACHED [publish 1/1] RUN dotnet publish "xxx.csproj" -c Release -o /app/publish             
 => CACHED [final 2/2] COPY --from=publish /app/publish .                                       
 => exporting to image                                                                          
 => => exporting layers                                                                         
 => => writing image sha256:484ba79107d8ae9652ed86159cf622f4cee395e6edb4b48ea3b0c298c33b8364    
 => => naming to <http://docker.io/library/test|docker.io/library/test>
e

echoing-dinner-19531

01/17/2022, 9:47 AM
I don't think there's a workaround for this currently. The issue is that the build step isn't part of the CRUD lifecycle its just done as part of the image constructor. We do have issues about this: https://github.com/pulumi/pulumi-docker/issues/132. Comment on there suggest giving https://github.com/MaterializeInc/pulumi-docker-buildkit a try.
🙌 1
q

quick-fall-21011

01/17/2022, 12:30 PM
Thanks @echoing-dinner-19531
4 Views