<p>After trying in vain to do this same &quot;chaining&quot; myself, I finally believe the claim made in Packer's <a href="https://www.packer.io/guides/packer-on-cicd/pipelineing-builds#chaining-together-several-of-the-same-builders-to-make-save-points" rel="nofollow noreferrer">documentation that you link to</a>:</p>
<blockquote>
<p>Packer templates don't come with a custom &quot;glue&quot; to bind them together. We recommend using your CI system or wrapping scripts to connect the templates into a chain.</p>
</blockquote>
<p>The largest problem lies in the fact that Packer builds for AWS AMIs require the source AMI ID in order to do pre-build validations. So if a single template will build two AMIs, neither of them can reference the AMI ID of the other, because that's unknown during pre-build validations.</p>

CC BY-SA 4.0
2023-04-20T12:43:17.090Z
Would it be better to build a raw image locally then upload to AWS?
Peter Turner
CC BY-SA 4.0
2023-04-20T19:42:28.027Z
@PeterTurner Yes, that would be an option.  AWS accepts imports of several VM formats that packer supports. This would open up some chaining possibilities within packer, though again, there would still need to be some "glue" logic in a script outside packer for importing to AWS.
Indigenuity
CC BY-SA 4.0
2023-04-19T19:02:45.967Z
2023-04-19T19:02:45.967Z
Indigenuity
<p>I would like to define a single Packer template that consists of 3 builds; each one building upon the previous:</p>
<pre><code>source &quot;amazon-ebs&quot; &quot;base&quot; {
  source_ami_filter {
    filters {
      ...
    }
}

build {
  name = &quot;build_1&quot;
  source &quot;amazon-ebs.base&quot; {
    ami_name = &quot;build-1-ami&quot;
  }
}

build {
  name = &quot;build_2&quot;
  source &quot;amazon-ebs.base&quot; {
    ami_name = &quot;build-2-ami
    source_ami = build_1.output.ami_id
    source_ami_filter { filters = {} }
  }
}

build {
  name = &quot;build_3&quot;
  source &quot;amazon-ebs.base&quot; {
    ami_name = &quot;base-3-ami
    source_ami = build_2.output.ami_id
    source_ami_filter { filters = {} }
  }
}
</code></pre>
<p>I know that it is possible to chain builders in some way (<a href="https://www.packer.io/guides/packer-on-cicd/pipelineing-builds#chaining-together-several-of-the-same-builders-to-make-save-points" rel="nofollow noreferrer">https://www.packer.io/guides/packer-on-cicd/pipelineing-builds#chaining-together-several-of-the-same-builders-to-make-save-points</a>). However, that example is using Docker and doing it a little more indirectly.</p>
<p>Is it possible to refer directly to the AMI ID produced by a previous build stage? I know <code>build_x.output.ami_id</code> is incorrect but is there a syntax to allow it?</p>
<p>If so, I think I also need to override/unset the <code>source_ami_filter</code> from the source because the documentation says when <code>source_ami</code> and <code>source_ami_filter</code> are used together then <code>source_ami</code> has to meet the other criteria of the filter which won't necessarily be the case.</p>

<packer>
How can I chain Packer builds within a single template
user3175543
# How can I chain Packer builds within a single template

(Asked by: username_0 on 2021-09-01)

I would like to define a single Packer template that consists of 3 builds; each one building upon the previous:
source "amazon-ebs" "base" {
  source_ami_filter {
    filters {
      ...
    }
}

build {
  name = "build_1"
  source "amazon-ebs.base" {
    ami_name = "build-1-ami"
  }
}

build {
  name = "build_2"
  source "amazon-ebs.base" {
    ami_name = "build-2-ami
    source_ami = build_1.output.ami_id
    source_ami_filter { filters = {} }
  }
}

build {
  name = "build_3"
  source "amazon-ebs.base" {
    ami_name = "base-3-ami
    source_ami = build_2.output.ami_id
    source_ami_filter { filters = {} }
  }
}

I know that it is possible to chain builders in some way (https://www.packer.io/guides/packer-on-cicd/pipelineing-builds#chaining-together-several-of-the-same-builders-to-make-save-points). However, that example is using Docker and doing it a little more indirectly.
Is it possible to refer directly to the AMI ID produced by a previous build stage? I know build_x.output.ami_id is incorrect but is there a syntax to allow it?
If so, I think I also need to override/unset the source_ami_filter from the source because the documentation says when source_ami and source_ami_filter are used together then source_ami has to meet the other criteria of the filter which won't necessarily be the case.

**Tags:** packer


---

## 1 answers

### Answer by username_1 on 2023-04-19. Score: 1

After trying in vain to do this same "chaining" myself, I finally believe the claim made in Packer's [documentation that you link to](https://www.packer.io/guides/packer-on-cicd/pipelineing-builds#chaining-together-several-of-the-same-builders-to-make-save-points):

> Packer templates don't come with a custom "glue" to bind them together. We recommend using your CI system or wrapping scripts to connect the templates into a chain.

The largest problem lies in the fact that Packer builds for AWS AMIs require the source AMI ID in order to do pre-build validations. So if a single template will build two AMIs, neither of them can reference the AMI ID of the other, because that's unknown during pre-build validations.

> **Comments:**
> **username_2**: Would it be better to build a raw image locally then upload to AWS?  
> **username_1**: @PeterTurner Yes, that would be an option.  AWS accepts imports of several VM formats that packer supports. This would open up some chaining possibilities within packer, though again, there would still need to be some "glue" logic in a script outside packer for importing to AWS.  

---

