Has anyone else run into an issue when trying to use Pulumi to build docker images, where you have a single Dockerfile, but two different targets in that Dockerfile and you want to build those two targets seperately? For example... I have a Dockerfile which has a "base" target, and then two additional targets "migrations" and "production" which extend from the "base". I have two Image resources in my Pulumi code which target the "migrations" and "production" targets separately. However, when I do this, despite the resources having different "names" I get the error:

Duplicate resource URN

on the second image build. The URN in question looks like one that is auto created by the Image resource with a name of

838fab2f-container

.

Can you post the code please? The duplicate URN refers to the first positional argument in the resource

@dry-keyboard-94795 here is the relevant code:

export const migratorRepo = new awsx.ecr.Repository(`${stackName}-migrator`, {
  lifecyclePolicy: {
    rules: [{ maximumNumberOfImages: 25, tagStatus: 'any' }],
  },
});

export const appsRepo = new awsx.ecr.Repository(`${stackName}-api`, {
  lifecyclePolicy: {
    rules: [{ maximumNumberOfImages: 25, tagStatus: 'any' }],
  },
});

checkForBuildx();

const migratorImage = new awsx.ecr.Image(PREFIX + 'migrator', {
  repositoryUrl: migratorRepo.url,
  context: path.join(__dirname, '../../../../'),
  dockerfile: path.join(__dirname, '../../', 'Dockerfile'),
  platform: 'linux/amd64',
  target: 'migration',
  cacheFrom: ["base"],
  args: {
    BUILDKIT_INLINE_CACHE: "1",
  },
});

const apiImage = new awsx.ecr.Image(PREFIX + 'api', {
  repositoryUrl: appsRepo.url,
  context: path.join(__dirname, '../../../../'),
  dockerfile: path.join(__dirname, '../../', 'Dockerfile'),
  platform: 'linux/amd64',
  target: 'production',
  cacheFrom: ["base"],
  args: {
    BUILDKIT_INLINE_CACHE: "1",
  },
});

Yep, I see the code looks incorrect here: https://github.com/pulumi/pulumi-awsx/blob/52e698db4d85d7fd4fa292027d04766ce4b1ceba/awsx/ecr/image.ts#L93 As a workaround, you can give one of the images a stub

args

so it generates a different name

So basically just fake it out, by adding something like a

X_IMAGE_NAME='migrator'

arg (which does nothing) to bust the cache?

Yep (though not cache related)

Right, poor choice of word