Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2023-04-20T12:43:17.090Z
Answers: Would it be better to build a raw image locally then upload to AWS?
Answers: Peter Turner
Answers: CC BY-SA 4.0
Answers: 2023-04-20T19:42:28.027Z
Answers: @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.
Answers: Indigenuity
Answers: CC BY-SA 4.0
Answers: 2023-04-19T19:02:45.967Z
Answers: 2023-04-19T19:02:45.967Z
Answers: Indigenuity
Body: <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>
  
Tags: <packer>
Title: How can I chain Packer builds within a single template
UserDisplayName: user3175543
ThreadText: # 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**: @username_2 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.  
  
  ---
  
  