mirror of
https://github.com/hashicorp/packer.git
synced 2026-10-07 23:20:24 -04:00
Merge pull request #13671 from hashicorp/remove-old-website
chore: remove website, fix:references
This commit is contained in:
eshan-tripathi
@@ -9,6 +9,5 @@ project {
|
||||
"examples/**",
|
||||
"hcl2template/fixtures/**",
|
||||
"command/plugin.go",
|
||||
"website/**" # candidates for copyright are coming from external sources, so we should not handle those in Packer
|
||||
]
|
||||
}
|
||||
|
||||
@@ -272,8 +272,8 @@ does not attempt to track the latest version for each dependency.
|
||||
#### Code generation
|
||||
|
||||
Packer relies on `go generate` to generate a [peg parser for boot
|
||||
commands](https://github.com/hashicorp/packer/blob/master/packer-plugin-sdk/bootcommand/boot_command.go),
|
||||
[docs](https://github.com/hashicorp/packer/blob/master/website/pages/partials/builder/amazon/chroot/_Config-not-required.mdx)
|
||||
commands](https://github.com/hashicorp/packer-plugin-sdk/blob/main/bootcommand/boot_command.go),
|
||||
[docs](https://github.com/hashicorp/packer-plugin-amazon/blob/main/docs-partials/builder/chroot/Config-not-required.mdx)
|
||||
and HCL2's bridging code. Packer's testing suite will run `make generate-check`
|
||||
to check that all the generated files Packer needs are what they should be.
|
||||
`make generate` re-generates all these file and can take a while depending on
|
||||
|
||||
@@ -2,9 +2,6 @@
|
||||
/local
|
||||
/pkg
|
||||
/src
|
||||
/website/.sass-cache
|
||||
/website/build
|
||||
/website/tmp
|
||||
.DS_Store
|
||||
.vagrant
|
||||
.idea
|
||||
@@ -15,9 +12,6 @@ test/.env
|
||||
|
||||
vendor/
|
||||
|
||||
website/.bundle
|
||||
website/vendor
|
||||
|
||||
packer-test*.log
|
||||
|
||||
*.received.txt
|
||||
|
||||
@@ -22,7 +22,7 @@ GOLDFLAGS=-X $(GIT_IMPORT).GitCommit=$(GIT_COMMIT)$(GIT_DIRTY) $(LDFLAGS)
|
||||
|
||||
export GOLDFLAGS
|
||||
|
||||
.PHONY: bin checkversion ci ci-lint default install-build-deps install-gen-deps fmt fmt-docs fmt-examples generate install-lint-deps lint \
|
||||
.PHONY: bin checkversion ci ci-lint default install-build-deps install-gen-deps fmt fmt-examples generate install-lint-deps lint \
|
||||
releasebin test testacc testrace version
|
||||
|
||||
default: install-build-deps install-gen-deps generate dev
|
||||
@@ -112,9 +112,6 @@ fmt-check: fmt ## Check go code formatting
|
||||
exit 1; \
|
||||
fi
|
||||
|
||||
fmt-docs:
|
||||
@find ./website/pages/docs -name "*.md" -exec pandoc --wrap auto --columns 79 --atx-headers -s -f "markdown_github+yaml_metadata_block" -t "markdown_github+yaml_metadata_block" {} -o {} \;
|
||||
|
||||
# Install js-beautify with npm install -g js-beautify
|
||||
fmt-examples:
|
||||
find examples -name *.json | xargs js-beautify -r -s 2 -n -eol "\n"
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
<p align="center" style="text-align:center;">
|
||||
<a href="https://www.packer.io">
|
||||
<img alt="HashiCorp Packer logo" src="website/public/img/logo-packer-padded.svg" width="500" />
|
||||
<img alt="HashiCorp Packer logo" src="assets/public/img/logo-packer-padded.svg" width="500" />
|
||||
</a>
|
||||
</p>
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 5.2 KiB After Width: | Height: | Size: 5.2 KiB |
@@ -1,18 +0,0 @@
|
||||
# This file is for unifying the coding style for different editors and IDEs
|
||||
# editorconfig.org
|
||||
|
||||
root = true
|
||||
|
||||
[*]
|
||||
end_of_line = lf
|
||||
charset = utf-8
|
||||
insert_final_newline = true
|
||||
trim_trailing_whitespace = true
|
||||
indent_style = space
|
||||
indent_size = 2
|
||||
|
||||
[Makefile]
|
||||
indent_style = tab
|
||||
|
||||
[{*.md,*.json}]
|
||||
max_line_length = null
|
||||
@@ -1,3 +0,0 @@
|
||||
NEXT_PUBLIC_ALGOLIA_APP_ID=YY0FFNI7MF
|
||||
NEXT_PUBLIC_ALGOLIA_INDEX=product_PACKER
|
||||
NEXT_PUBLIC_ALGOLIA_SEARCH_ONLY_API_KEY=4e1ea7f4bf4335ac43d9f28463e42148
|
||||
@@ -1 +0,0 @@
|
||||
HASHI_ENV=production
|
||||
@@ -1,4 +0,0 @@
|
||||
module.exports = {
|
||||
...require('@hashicorp/platform-cli/config/.eslintrc'),
|
||||
ignorePatterns: ['public/']
|
||||
}
|
||||
@@ -1,11 +0,0 @@
|
||||
node_modules
|
||||
.DS_Store
|
||||
.next
|
||||
out
|
||||
.mdx-data
|
||||
|
||||
# As per Next.js conventions (https://nextjs.org/docs/basic-features/environment-variables#default-environment-variables)
|
||||
!.env
|
||||
.env*.local
|
||||
|
||||
website-preview
|
||||
@@ -1,3 +0,0 @@
|
||||
cd website
|
||||
|
||||
npx next-hashicorp precommit
|
||||
@@ -1 +0,0 @@
|
||||
v22
|
||||
@@ -1,4 +0,0 @@
|
||||
module.exports = {
|
||||
...require('@hashicorp/platform-cli/config/stylelint.config'),
|
||||
/* Specify overrides here */
|
||||
}
|
||||
@@ -1,8 +0,0 @@
|
||||
FROM docker.mirror.hashicorp.services/node:22.17.1-alpine
|
||||
RUN apk add --update --no-cache git make g++ automake autoconf libtool nasm libpng-dev
|
||||
|
||||
COPY ./package.json /website/package.json
|
||||
COPY ./package-lock.json /website/package-lock.json
|
||||
WORKDIR /website
|
||||
RUN npm install -g npm@latest
|
||||
RUN npm install
|
||||
@@ -1,10 +0,0 @@
|
||||
# Proprietary License
|
||||
|
||||
This license is temporary while a more official one is drafted. However,
|
||||
this should make it clear:
|
||||
|
||||
The text contents of this website are MPL 2.0 licensed.
|
||||
|
||||
The design contents of this website are proprietary and may not be reproduced
|
||||
or reused in any way other than to run the website locally. The license for
|
||||
the design is owned solely by HashiCorp, Inc.
|
||||
@@ -1,60 +0,0 @@
|
||||
######################################################
|
||||
# NOTE: This file is managed by the Digital Team's #
|
||||
# Terraform configuration @ hashicorp/mktg-terraform #
|
||||
######################################################
|
||||
|
||||
.DEFAULT_GOAL := website
|
||||
|
||||
# Set the preview mode for the website shell to "developer" or "io"
|
||||
PREVIEW_MODE ?= developer
|
||||
REPO ?= packer
|
||||
|
||||
# Enable setting alternate docker tool, e.g. 'make DOCKER_CMD=podman'
|
||||
DOCKER_CMD ?= docker
|
||||
|
||||
CURRENT_GIT_BRANCH=$$(git rev-parse --abbrev-ref HEAD)
|
||||
LOCAL_CONTENT_DIR=
|
||||
PWD=$$(pwd)
|
||||
|
||||
DOCKER_IMAGE="hashicorp/dev-portal"
|
||||
DOCKER_IMAGE_LOCAL="dev-portal-local"
|
||||
DOCKER_RUN_FLAGS=-it \
|
||||
--publish "3000:3000" \
|
||||
--rm \
|
||||
--tty \
|
||||
--volume "$(PWD)/content:/app/content" \
|
||||
--volume "$(PWD)/public:/app/public" \
|
||||
--volume "$(PWD)/data:/app/data" \
|
||||
--volume "$(PWD)/redirects.js:/app/redirects.js" \
|
||||
--volume "next-dir:/app/website-preview/.next" \
|
||||
--volume "$(PWD)/.env:/app/.env" \
|
||||
--volume "$(PWD)/.env.development:/app/website-preview/.env.development" \
|
||||
--volume "$(PWD)/.env.local:/app/website-preview/.env.local" \
|
||||
-e "REPO=$(REPO)" \
|
||||
-e "PREVIEW_FROM_REPO=$(REPO)" \
|
||||
-e "IS_CONTENT_PREVIEW=true" \
|
||||
-e "LOCAL_CONTENT_DIR=$(LOCAL_CONTENT_DIR)" \
|
||||
-e "CURRENT_GIT_BRANCH=$(CURRENT_GIT_BRANCH)" \
|
||||
-e "PREVIEW_MODE=$(PREVIEW_MODE)"
|
||||
|
||||
# Default: run this if working on the website locally to run in watch mode.
|
||||
.PHONY: website
|
||||
website:
|
||||
@echo "==> Downloading latest Docker image..."
|
||||
@$(DOCKER_CMD) pull $(DOCKER_IMAGE)
|
||||
@echo "==> Starting website..."
|
||||
@$(DOCKER_CMD) run $(DOCKER_RUN_FLAGS) $(DOCKER_IMAGE)
|
||||
|
||||
# Use this if you have run `website/build-local` to use the locally built image.
|
||||
.PHONY: website/local
|
||||
website/local:
|
||||
@echo "==> Starting website from local image..."
|
||||
@$(DOCKER_CMD) run $(DOCKER_RUN_FLAGS) $(DOCKER_IMAGE_LOCAL)
|
||||
|
||||
# Run this to generate a new local Docker image.
|
||||
.PHONY: website/build-local
|
||||
website/build-local:
|
||||
@echo "==> Building local Docker image"
|
||||
@$(DOCKER_CMD) build https://github.com/hashicorp/dev-portal.git\#main \
|
||||
-t $(DOCKER_IMAGE_LOCAL)
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,47 +0,0 @@
|
||||
---
|
||||
page_title: Community vs HashiCorp Maintained Plugins
|
||||
description: Packer maintains these core plugins.
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# HashiCorp Maintained Plugins
|
||||
|
||||
The following plugins (i.e. Builders, Provisioners, and Post-Processors) are
|
||||
maintained by HashiCorp. Any plugins not on this list are maintained by the
|
||||
community, and not actively contributed to by HashiCorp, although they are
|
||||
still distributed with Packer. If you are interested in seeing features or
|
||||
bugfixes to these plugins, please consider making a pull request, or asking the
|
||||
HashiCorp maintainers for advice on how to get started contributing.
|
||||
|
||||
## Builders
|
||||
|
||||
- Amazon EC2
|
||||
- Azure
|
||||
- Docker
|
||||
- Google Cloud
|
||||
- VMware
|
||||
- VirtualBox
|
||||
|
||||
## Provisioners
|
||||
|
||||
- File
|
||||
- HCP SBOM
|
||||
- InSpec
|
||||
- PowerShell
|
||||
- Shell
|
||||
- Windows Restart
|
||||
- Windows Shell
|
||||
|
||||
## Post-Processors
|
||||
|
||||
- Amazon Import
|
||||
- Artifice
|
||||
- Docker
|
||||
- Local Shell
|
||||
- Manifest
|
||||
- Vagrant
|
||||
- Vagrant Cloud
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
description: |
|
||||
Community-supported builders are developed and maintained by third-parties and not HashiCorp. Use them with Packer to extend Packer functionality.
|
||||
page_title: Community-supported builders
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Community-supported builders
|
||||
|
||||
The following builders are developed and maintained by various members of the
|
||||
Packer community, not by HashiCorp. For more information on how to use community
|
||||
builders, refer to our docs on [extending Packer](/packer/docs/plugins/creation).
|
||||
|
||||
- ARM builders
|
||||
|
||||
- [packer-plugin-arm-image](https://github.com/solo-io/packer-plugin-arm-image): Lets you extend onto existing system images.
|
||||
- [packer-builder-arm](https://github.com/mkaczanowski/packer-builder-arm): Lets you extend or build new images with a variety of options, such as custom partition tables.
|
||||
|
||||
- [Exoscale builder](https://github.com/exoscale/packer-plugin-exoscale) - Creates Exoscale custom templates based on a compute instance snapshot.
|
||||
|
||||
- [Citrix XenServer/Citrix Hypervisor](https://github.com/xenserver/packer-builder-xenserver) - Plugin for creating [Citrix XenServer/Citrix Hypervisor](https://xenserver.org/) images from an ISO image or from an existing template.
|
||||
|
||||
- [XCP-NG/Citrix XenServer/Citrix Hypervisor/Updated Fork](https://github.com/ddelnano/packer-plugin-xenserver) - Plugin for creating [XCP-NG/Citrix XenServer/Citrix Hypervisor](https://xcp-ng.org/) images from an ISO image or from an existing template. This is a fork of the orginal and reccomended by the developers of XCP-NG.
|
||||
@@ -1,76 +0,0 @@
|
||||
---
|
||||
description: |
|
||||
The `file` builder creates an artifact from a file. Use the `file` builder to debug post-processors without incurring long wait times.
|
||||
page_title: file builder reference
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
<BadgesHeader>
|
||||
<PluginBadge type="official" />
|
||||
</BadgesHeader>
|
||||
|
||||
# `file` builder
|
||||
|
||||
The `file` builder creates an artifact from a file. You can use it to debug post-processors without incurring long wait times.
|
||||
|
||||
Artifact `BuilderId`: `packer.file`
|
||||
|
||||
## Basic Example
|
||||
|
||||
Below is a fully functioning example. It create a file at `target` with the
|
||||
specified `content`.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
source "file" "basic-example" {
|
||||
content = "Lorem ipsum dolor sit amet"
|
||||
target = "dummy_artifact"
|
||||
}
|
||||
|
||||
build {
|
||||
sources = ["sources.file.basic-example"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "file",
|
||||
"content": "Lorem ipsum dolor sit amet",
|
||||
"target": "dummy_artifact"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Configuration Reference
|
||||
|
||||
Configuration options are organized below into two categories: required and
|
||||
optional. Within each category, the available options are alphabetized and
|
||||
described.
|
||||
|
||||
Any [communicator](/packer/docs/templates/legacy_json_templates/communicator) defined is ignored.
|
||||
|
||||
### Required
|
||||
|
||||
- `target` (string) - The path for the artifact file that will be created. If
|
||||
the path contains directories that don't exist, Packer will create them, too.
|
||||
|
||||
### Optional
|
||||
|
||||
You can only define one of `source` or `content`. If none of them is defined
|
||||
the artifact will be empty.
|
||||
|
||||
- `source` (string) - The path for a file which will be copied as the
|
||||
artifact.
|
||||
|
||||
- `content` (string) - The content that will be put into the artifact.
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
description: |
|
||||
Builders create machines and generate images from them for various platforms. Learn about the types of builders you can use in your Packer templates.
|
||||
page_title: Builders overview
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Builders overview
|
||||
|
||||
Builders create machines and generate images from those machines for various platforms. Some builders in Packer perform helper tasks, such as running provisioners.
|
||||
|
||||
Packer has the following types of builders:
|
||||
|
||||
- [Plugins](/packer/plugins): Plugins that you install have their own associated set of builders. For example, EC2, VMware, and VirtualBox use their own separate sets of builders.
|
||||
- [`file`](/packer/docs/builders/file): The `file` builder creates an artifact from a file.
|
||||
- [`null`](/packer/docs/builders/null): The `null` builder sets up an SSH connection and runs the provisioners.
|
||||
- [Custom](/packer/docs/plugins/creation/custom-builders): You can write new builders for new or existing platforms.
|
||||
- [Community-supported](/packer/docs/builders/community-supported): The Packer community develops and maintains builders for several additional platforms.
|
||||
|
||||
Refer to the [`source`](/packer/docs/templates/hcl_templates/blocks/source) block documentation to learn more about configuring builders in the Packer templating language.
|
||||
|
||||
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
description: |
|
||||
The `null` builder creates an SSH connection and runs provisioners. Use the `null` builder to debug provisioners without incurring long wait times.
|
||||
page_title: null builder reference
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
<BadgesHeader>
|
||||
<PluginBadge type="official" />
|
||||
</BadgesHeader>
|
||||
|
||||
# `null` builder
|
||||
|
||||
The `null` builder sets up an SSH connection and runs provisioners. You can use it to debug provisioners without incurring long wait times. It does not create a images or artifacts.
|
||||
|
||||
## Basic Example
|
||||
|
||||
Below is a fully functioning example. It doesn't do anything useful, since no
|
||||
provisioners are defined, but it will connect to the specified host via ssh.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
source "null" "basic-example" {
|
||||
ssh_host = "127.0.0.1"
|
||||
ssh_username = "foo"
|
||||
ssh_password = "bar"
|
||||
}
|
||||
|
||||
build {
|
||||
sources = ["sources.null.basic-example"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "null",
|
||||
"ssh_host": "127.0.0.1",
|
||||
"ssh_username": "foo",
|
||||
"ssh_password": "bar"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Configuration Reference
|
||||
|
||||
The null builder has no configuration parameters other than the
|
||||
[communicator](/packer/docs/templates/legacy_json_templates/communicator) settings.
|
||||
@@ -1,76 +0,0 @@
|
||||
---
|
||||
description: |
|
||||
The `packer build` command builds all of the artifacts defined in a template. Builds can run in parallel or sequentially.
|
||||
page_title: packer build - Commands
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# `packer build` command reference
|
||||
|
||||
<Note>
|
||||
|
||||
Starting August 1st, 2025, the source for many official HashiCorp-maintained Packer plugins is moving from GitHub releases to the official HashiCorp release site, [releases.hashicorp.com](https://releases.hashicorp.com). Refer to [Install HashiCorp-maintained plugins](/packer/docs/plugins/install#install-hashicorp-maintained-plugins) for more information.
|
||||
|
||||
</Note>
|
||||
|
||||
The `packer build` command takes a template and runs all the builds within it
|
||||
in order to generate a set of artifacts. The various builds specified within a
|
||||
template are executed in parallel, unless otherwise specified. And the
|
||||
artifacts that are created will be outputted at the end of the build.
|
||||
|
||||
## Options
|
||||
|
||||
- `-color=false` - Disables colorized output. Enabled by default.
|
||||
|
||||
- `-debug` - Disables parallelization and enables debug mode. Debug mode
|
||||
flags the builders that they should output debugging information. The exact
|
||||
behavior of debug mode is left to the builder. In general, builders usually
|
||||
will stop between each step, waiting for keyboard input before continuing.
|
||||
This will allow the user to inspect state and so on.
|
||||
|
||||
`@include 'commands/except.mdx'`
|
||||
|
||||
- `-force` - Forces a builder to run when artifacts from a previous build
|
||||
prevent a build from running. The exact behavior of a forced build is left
|
||||
to the builder. In general, a builder supporting the forced build will
|
||||
remove the artifacts from the previous build. This will allow the user to
|
||||
repeat a build without having to manually clean these artifacts beforehand.
|
||||
|
||||
- `-on-error=cleanup` (default), `-on-error=abort`, `-on-error=ask`, `-on-error=run-cleanup-provisioner` -
|
||||
Selects what to do when the build fails during provisioning. Please note that
|
||||
this only affects the build during the provisioner run, not during the
|
||||
post-processor run, because it is related to whether or not to keep the
|
||||
instance running and related artifacts like generated SSH keys on the system
|
||||
when a provisioner fails.
|
||||
|
||||
- `cleanup` cleans up after the previous steps, deleting temporary files and virtual machines.
|
||||
- `abort` exits without any cleanup, which might require the next build to use `-force`.
|
||||
- `ask` presents a prompt and waits for you to decide to clean up, abort, or retry
|
||||
the failed step.
|
||||
- `run-cleanup-provisioner` aborts and exits without any cleanup besides
|
||||
the [error-cleanup-provisioner](/packer/docs/templates/legacy_json_templates/provisioners#on-error-provisioner) if one is defined.
|
||||
|
||||
`@include 'commands/only.mdx'`
|
||||
|
||||
- `-parallel-builds=N` - Limit the number of builds to run in parallel, 0
|
||||
means no limit (defaults to 0).
|
||||
|
||||
- `-timestamp-ui` - Enable prefixing of each ui output with an RFC3339
|
||||
timestamp.
|
||||
|
||||
- `-var` - Set a variable in your Packer template. This option can be used
|
||||
multiple times. This is useful for setting version numbers for your build.
|
||||
|
||||
- `-var-file` - Set template variables from a file.
|
||||
|
||||
- `-warn-on-undeclared-var` - Setting this flag will yield a warning for each assignment within
|
||||
a variable definitions file (*.pkrvars.hcl | *.pkrvars.json) that does not have an accompanying
|
||||
variable block. This can occur when using a var-file that contains a large amount of unused variables
|
||||
for a given HCL2 template. For HCL2 template builds defining a value for a variable in a var-file is
|
||||
not enough on its own for Packer to function, as there also needs to be a variable block definition in
|
||||
the template files `pkr.hcl` for the variable. By default `packer build` will not warn when a var-file
|
||||
contains one or more undeclared variables.
|
||||
@@ -1,160 +0,0 @@
|
||||
---
|
||||
description: |
|
||||
The `packer console` command starts an interactive console, letting you experiment with Packer variable interpolations.
|
||||
page_title: packer console command reference
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# `packer console` command reference
|
||||
|
||||
The `packer console` command allows you to experiment with Packer variable
|
||||
interpolations. You may access variables in the Packer config you called the
|
||||
console with, or provide variables when you call console using the -var or
|
||||
-var-file command line options.
|
||||
|
||||
~> **Note:** `console` is available from version 1.4.2 and above.
|
||||
|
||||
~> **Note:** For HCL2 `console` is available from version 1.6.0 and above, use
|
||||
`packer console --config-type=hcl2` to try it without a config file. Go
|
||||
templating ( or `{{..}}` calls ) will not work in HCL2 mode.
|
||||
|
||||
Type in the interpolation to test and hit `<enter>` to see the result.
|
||||
|
||||
To exit the console, type "exit" and hit `<enter>`, or use Control-C.
|
||||
|
||||
```shell-session
|
||||
$ packer console my_template.json
|
||||
```
|
||||
|
||||
The full list of options that the console command will accept is visible in the
|
||||
help output, which can be seen via `packer console -h`.
|
||||
|
||||
## Options
|
||||
|
||||
- `-var` - Set a variable in your Packer template. This option can be used
|
||||
multiple times. This is useful for setting version numbers for your build.
|
||||
example: `-var "myvar=asdf"`
|
||||
|
||||
- `-var-file` - Set template variables from a file.
|
||||
example: `-var-file myvars.json`
|
||||
|
||||
## REPL commands
|
||||
|
||||
- `help` - displays help text for Packer console.
|
||||
|
||||
- `exit` - exits the console
|
||||
|
||||
- `variables` - prints a list of all variables read into the console from the
|
||||
`-var` option, `-var-files` option, and template.
|
||||
|
||||
## Usage Examples - repl session ( JSON )
|
||||
|
||||
Let's say you launch a console using a Packer template `example_template.json`:
|
||||
|
||||
```shell-session
|
||||
$ packer console example_template.json
|
||||
```
|
||||
|
||||
You'll be dropped into a prompt that allows you to enter template functions and
|
||||
see how they're evaluated; for example, if the variable `myvar` is defined in
|
||||
your example_template's variable section:
|
||||
|
||||
```json
|
||||
"variables":{
|
||||
"myvar": "asdfasdf"
|
||||
},
|
||||
...
|
||||
```
|
||||
|
||||
and you enter `` {{user `myvar`}} `` in the Packer console, you'll see the value of
|
||||
myvar:
|
||||
|
||||
```shell-session
|
||||
> {{user `myvar`}}
|
||||
asdfasdf
|
||||
```
|
||||
|
||||
From there you can test more complicated interpolations:
|
||||
|
||||
```shell-session
|
||||
> {{user `myvar`}}-{{timestamp}}
|
||||
asdfasdf-1559854396
|
||||
```
|
||||
|
||||
And when you're done using the console, just type "exit" or CTRL-C
|
||||
|
||||
```shell-session
|
||||
> exit
|
||||
$
|
||||
```
|
||||
|
||||
If you'd like to provide a variable or variable files, you'd do this:
|
||||
|
||||
```shell-session
|
||||
$ packer console -var "myvar=fdsafdsa" -var-file myvars.json example_template.json
|
||||
```
|
||||
|
||||
If you don't have specific variables or var files you want to test, and just
|
||||
want to experiment with a particular template engine, you can do so by simply
|
||||
calling `packer console` without a template file.
|
||||
|
||||
## Usage Examples - piped commands ( JSON )
|
||||
|
||||
If you'd like to just see a specific single interpolation without launching
|
||||
the REPL, you can do so by echoing and piping the string into the console
|
||||
command:
|
||||
|
||||
```shell-session
|
||||
$ echo {{timestamp}} | packer console
|
||||
1559855090
|
||||
```
|
||||
|
||||
## Usage Examples - repl session ( HCL2 )
|
||||
|
||||
~> **Note:** For HCL2 `console` is available from version 1.6.0 and above, use
|
||||
`packer console --config-type=hcl2` to try it without a config file. Go
|
||||
templating ( or `{{..}}` calls ) will not work in HCL2 mode.
|
||||
|
||||
Without a config file, `packer console` can be used to experiment with the
|
||||
expression syntax and [built-in functions](/packer/docs/templates/hcl_templates/functions).
|
||||
|
||||
### Starting
|
||||
|
||||
To start a session on a folder containing HCL2 config files, run:
|
||||
|
||||
```shell-session
|
||||
packer console folder/
|
||||
```
|
||||
|
||||
Because `folder/` is a folder Packer will start in HCL2 mode, you can also
|
||||
directly pass an HCL2 formatted config file:
|
||||
|
||||
```shell-session
|
||||
packer console file.pkr.hcl
|
||||
```
|
||||
|
||||
Because the file is suffixed with `.pkr.hcl` Packer will start in HCL2 mode.
|
||||
|
||||
When you just want to play around without a config file you can set the
|
||||
`--config-type=hcl2` option and Packer will start in HCL2 mode:
|
||||
|
||||
```shell-session
|
||||
packer console --config-type=hcl2
|
||||
```
|
||||
|
||||
### Scripting
|
||||
|
||||
The `packer console` command can be used in non-interactive scripts by piping
|
||||
newline-separated commands to it. Only the output from the final command is
|
||||
printed unless an error occurs earlier.
|
||||
|
||||
For example:
|
||||
|
||||
```shell-session
|
||||
$ echo "1 + 5" | packer console
|
||||
6
|
||||
```
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
description: |
|
||||
The `packer fix` command updates backward incompatible templates for the running version of Packer.
|
||||
page_title: packer fix command reference
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# `packer fix` command reference
|
||||
|
||||
|
||||
The `packer fix` command takes a template and finds backward incompatible
|
||||
parts of it and brings it up to date so it can be used with the latest version
|
||||
of Packer. After you update to a new Packer release, you should run the fix
|
||||
command to make sure your templates work with the new release.
|
||||
|
||||
-> **JSON template-only command**: You cannot use the `packer fix` command to update HCL2 templates.
|
||||
|
||||
The fix command will output the changed template to standard out, so you should
|
||||
redirect standard out using standard OS-specific techniques if you want to save it
|
||||
to a file. For example, on Linux systems, you may want to do this:
|
||||
|
||||
```shell-session
|
||||
$ packer fix old.json > new.json
|
||||
```
|
||||
|
||||
If fixing fails for any reason, the fix command will exit with a non-zero exit
|
||||
status. Error messages appear on standard error, so if you're redirecting
|
||||
output, you'll still see error messages.
|
||||
|
||||
-> **Even when Packer fix doesn't do anything** to the template, the
|
||||
template will be outputted to standard out. Things such as configuration key
|
||||
ordering and indentation may be changed. The output format however, is
|
||||
pretty-printed for human readability.
|
||||
|
||||
The full list of fixes that the fix command performs is visible in the help
|
||||
output, which can be seen via `packer fix -h`.
|
||||
|
||||
## Options
|
||||
|
||||
- `-validate=false` - Disables validation of the fixed template. True by
|
||||
default.
|
||||
@@ -1,71 +0,0 @@
|
||||
---
|
||||
description: |
|
||||
The `packer fmt` Packer command formats HCL2 configuration files to a canonical format and style to help you prevent coding errors.
|
||||
page_title: packer fmt command reference
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# `packer fmt` command reference
|
||||
|
||||
The `packer fmt` Packer command is used to format HCL2 configuration files to
|
||||
a canonical format and style. JSON files (.json) are not modified. This command
|
||||
applies a subset of HCL language style conventions, along with other minor
|
||||
adjustments for readability.
|
||||
|
||||
`packer fmt` will display the name of the configuration file(s) that need formatting,
|
||||
and write any formatted changes back to the original configuration file(s).
|
||||
|
||||
Example usage:
|
||||
|
||||
Check if configuration file(s) need to be formatted, but don't write the changes.
|
||||
|
||||
```shell-session
|
||||
$ packer fmt -check .
|
||||
my-template.pkr.hcl
|
||||
|
||||
```
|
||||
|
||||
Format a configuration file, writing the changes back to the original file.
|
||||
|
||||
```shell-session
|
||||
$ packer fmt my-template.pkr.hcl
|
||||
my-template.pkr.hcl
|
||||
|
||||
```
|
||||
|
||||
Format multiple configuration files, writing the changes back to respective original files.
|
||||
|
||||
```shell-session
|
||||
$ packer fmt my-template.pkr.hcl my-varfile.pkrvars.hcl
|
||||
my-template.pkr.hcl
|
||||
my-varfile.pkrvars.hcl
|
||||
|
||||
```
|
||||
|
||||
Format a configuration file, reading from stdin and writing to stdout.
|
||||
|
||||
```shell-session
|
||||
$ packer fmt -
|
||||
|
||||
// You can use pipes to combine this feature with other command line options
|
||||
$ cat my-template.pkr.hcl | packer fmt -
|
||||
```
|
||||
|
||||
## Options
|
||||
|
||||
- `-check` - Checks if the input is formatted. Exit status will be 0 if all
|
||||
input is properly formatted and non-zero otherwise.
|
||||
|
||||
- `-diff` - Display diffs of any formatting change
|
||||
|
||||
- `-write=false` - Don't write formatting changes to source files
|
||||
(always disabled if using -check)
|
||||
|
||||
- `-` - read formatting changes from stdin and write them to stdout.
|
||||
|
||||
- `-recursive` Also process files in subdirectories. By default, only the
|
||||
given directory (or current directory) is processed.
|
||||
@@ -1,141 +0,0 @@
|
||||
---
|
||||
description: |
|
||||
The `packer hcl2_upgrade` Packer command transpiles a JSON
|
||||
configuration template into HCL2 so you can transition to HCL templates.
|
||||
page_title: packer hcl2_upgrade command reference
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# `packer hcl2_upgrade` command reference
|
||||
|
||||
The `packer hcl2_upgrade` Packer command transpiles a JSON
|
||||
configuration template to it's formatted HCL2 counterpart. The command
|
||||
returns a zero exit status on success and a non-zero exit status on failure.
|
||||
|
||||
-> **This command is beta**. We do not recommend using beta functionality in production environments. To report an issue and provide feedback, [open a GitHub
|
||||
issue](https://github.com/hashicorp/packer/issues/new/choose).
|
||||
|
||||
## Usage
|
||||
|
||||
```shell-session
|
||||
$ packer hcl2_upgrade my-template.json
|
||||
|
||||
Successfully created my-template.json.pkr.hcl
|
||||
```
|
||||
|
||||
## Upgrading variables file
|
||||
|
||||
From **v1.7.1**, the `hcl2_upgrade` command can upgrade a variables file.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="Original file (variables.json)">
|
||||
|
||||
```json
|
||||
{
|
||||
"variables": {
|
||||
"aws_region": null,
|
||||
"aws_secondary_region": "{{ env `AWS_DEFAULT_REGION` }}",
|
||||
"aws_secret_key": "",
|
||||
"aws_access_key": ""
|
||||
},
|
||||
"sensitive-variables": ["aws_secret_key", "aws_access_key"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="Result file (variables.pkr.hcl)">
|
||||
|
||||
```hcl
|
||||
variable "aws_access_key" {
|
||||
type = string
|
||||
default = ""
|
||||
sensitive = true
|
||||
}
|
||||
|
||||
variable "aws_region" {
|
||||
type = string
|
||||
}
|
||||
|
||||
variable "aws_secondary_region" {
|
||||
type = string
|
||||
default = "${env("AWS_DEFAULT_REGION")}"
|
||||
}
|
||||
|
||||
variable "aws_secret_key" {
|
||||
type = string
|
||||
default = ""
|
||||
sensitive = true
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Go template functions
|
||||
|
||||
`hcl2_upgrade` will do its best to transform your Go _template calls_ to HCL2,
|
||||
here is the list of calls that should get transformed:
|
||||
|
||||
- `` {{ user `my_var` }} `` becomes `${var.my_var}`.
|
||||
- `` {{ env `my_var` }} `` becomes `${var.my_var}`. Packer HCL2 supports
|
||||
environment variables through input variables. See
|
||||
[docs](/packer/docs/templates/hcl_templates/variables#environment-variables)
|
||||
for more info.
|
||||
- `{{ timestamp }}` becomes `${local.timestamp}`, the local variable
|
||||
will be created for all generated files.
|
||||
- `` {{ build `ID` }} `` becomes `${build.ID}`.
|
||||
|
||||
The rest of the calls should remain Go template calls for now, this will be
|
||||
improved over time.
|
||||
|
||||
-> **Note**: The `hcl2_upgrade` command does its best to transform template
|
||||
calls to their JSON counterpart, but it might fail. In that case the
|
||||
`hcl2_upgrade` command will simply output the local HCL2 block without
|
||||
transformation and with the error message in a comment. We are currently
|
||||
working on improving this part of the transformer.
|
||||
|
||||
## Options
|
||||
|
||||
- `-output-file` - Filename of the hcl2 generated template. Defaults to
|
||||
JSON_TEMPLATE.pkr.hcl; for example, if the file is called
|
||||
"packerparty.json", the default output-file is "packerparty.json.pkr.hcl".
|
||||
- `-with-annotations` - Adds helpful comments to the HCL template with
|
||||
information about the generated HCL2 blocks.
|
||||
|
||||
## User variables using other user variables
|
||||
|
||||
Packer JSON recently started allowing using user variables from variables. In
|
||||
HCL2, input variables cannot use functions nor other variables and are
|
||||
virtually static, local variables must be used instead to craft more dynamic
|
||||
variables.
|
||||
|
||||
For v1.7.0 and lower, `hcl2_upgrade` doesn't upgrade variables to local variables,
|
||||
and it is up to you to upgrade them manually. Upgrade to **v1.7.1** to let the command do it
|
||||
automatically for you.
|
||||
|
||||
Here is an example of a local variable using a string input variables:
|
||||
|
||||
```hcl
|
||||
variable "foo" {
|
||||
default = "Hello,"
|
||||
}
|
||||
|
||||
variable "bar" {
|
||||
default = "World!"
|
||||
}
|
||||
|
||||
locals {
|
||||
baz = "${var.foo} ${var.bar}"
|
||||
}
|
||||
```
|
||||
|
||||
## Upgrading templates that use third-party community plugins
|
||||
|
||||
If your template references a plugin that is not bundled with the main Packer
|
||||
binary, you need to make sure that the [plugin is installed](/packer/docs/plugins#installing-plugins)
|
||||
or you will get an `unknown builder type` error. Packer needs to load the plugin
|
||||
to transpose the template.
|
||||
@@ -1,167 +0,0 @@
|
||||
---
|
||||
description: |
|
||||
The Packer command-line interface lets you perform Packer operations. Use the `packer` CLI command with subcommands, flags, and options to build and manage artifacts and install and manage plugins.
|
||||
page_title: Packer commands overview
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# Packer Commands Overview
|
||||
|
||||
Packer is controlled using a command-line interface. All interaction with
|
||||
Packer is done via the `packer` tool. Like many other command-line tools, the
|
||||
`packer` tool takes a subcommand to execute, and that subcommand may have
|
||||
additional options as well. Subcommands are executed with `packer SUBCOMMAND`,
|
||||
where "SUBCOMMAND" is the actual command you wish to execute.
|
||||
|
||||
If you run `packer` by itself, help will be displayed showing all available
|
||||
subcommands and a brief synopsis of what they do. In addition to this, you can
|
||||
run any `packer` command with the `-h` flag to output more detailed help for a
|
||||
specific subcommand.
|
||||
|
||||
The documentation contains information about each subcommand.
|
||||
|
||||
## Machine-Readable Output
|
||||
|
||||
By default, the output of Packer is very human-readable. It uses nice
|
||||
formatting, spacing, and colors in order to make Packer a pleasure to use.
|
||||
However, Packer was built with automation in mind. To that end, Packer supports
|
||||
a fully machine-readable output setting, allowing you to use Packer in
|
||||
automated environments.
|
||||
|
||||
Because the machine-readable output format was made with Unix tools in mind, it
|
||||
is `awk`/`sed`/`grep`/etc. friendly and provides a familiar interface without
|
||||
requiring you to learn a new format.
|
||||
|
||||
### Enabling Machine-Readable Output
|
||||
|
||||
The machine-readable output format can be enabled by passing the
|
||||
`-machine-readable` flag to any Packer command. This immediately enables all
|
||||
output to become machine-readable on stdout. Logging, if enabled, continues to
|
||||
appear on stderr. An example of the output is shown below:
|
||||
|
||||
```shell-session
|
||||
$ packer -machine-readable version
|
||||
1498365963,,version,1.0.2
|
||||
1498365963,,version-prelease,
|
||||
1498365963,,version-commit,3ead2750b+CHANGES
|
||||
1498365963,,ui,say,Packer v1.0.2
|
||||
```
|
||||
|
||||
The format will be covered in more detail later. But as you can see, the output
|
||||
immediately becomes machine-friendly. Try some other commands with the
|
||||
`-machine-readable` flag to see!
|
||||
|
||||
~>; The `-machine-readable` flag is designed for automated environments and
|
||||
is mutually-exclusive with the `-debug` flag, which is designed for interactive
|
||||
environments.
|
||||
|
||||
### Format for Machine-Readable Output
|
||||
|
||||
The machine readable format is a line-oriented, comma-delimited text format.
|
||||
This makes it more convenient to parse using standard Unix tools such as `awk`
|
||||
or `grep` in addition to full programming languages like Ruby or Python.
|
||||
|
||||
The format is:
|
||||
|
||||
```text
|
||||
timestamp,target,type,data...
|
||||
```
|
||||
|
||||
Each component is explained below:
|
||||
|
||||
- `timestamp` is a Unix timestamp in UTC of when the message was printed.
|
||||
|
||||
- `target` When you call `packer build` this can be either empty or
|
||||
individual build names, e.g. `amazon-ebs`. It is normally empty when builds
|
||||
are in progress, and the build name when artifacts of particular builds are
|
||||
being referred to.
|
||||
|
||||
- `type` is the type of machine-readable message being outputted. The two
|
||||
most common `type`s are `ui` and `artifact`
|
||||
|
||||
- `data` is zero or more comma-separated values associated with the prior
|
||||
type. The exact amount and meaning of this data is type-dependent, so you
|
||||
must read the documentation associated with the type to understand fully.
|
||||
|
||||
Within the format, if data contains a comma, it is replaced with
|
||||
`%!(PACKER_COMMA)`. This was preferred over an escape character such as `\'`
|
||||
because it is more friendly to tools like `awk`.
|
||||
|
||||
Newlines within the format are replaced with their respective standard escape
|
||||
sequence. Newlines become a literal `\n` within the output. Carriage returns
|
||||
become a literal `\r`.
|
||||
|
||||
### Machine-Readable Message Types
|
||||
|
||||
Here's an incomplete list of types you may see in the machine-readable output:
|
||||
|
||||
You'll see these data types when you run `packer build`:
|
||||
|
||||
- `ui`: this means that the information being provided is a human-readable
|
||||
string that would be sent to stdout even if we aren't in machine-readable
|
||||
mode. There are three "data" subtypes associated with this type:
|
||||
|
||||
- `say`: in a non-machine-readable format, this would be bolded. Normally
|
||||
it is used for announcements about beginning new steps in the build
|
||||
process
|
||||
|
||||
- `message`: the most commonly used message type, used for basic updates
|
||||
during the build process.
|
||||
|
||||
- `error`: reserved for errors
|
||||
|
||||
- `artifact-count`: This data type tells you how many artifacts a particular
|
||||
build produced.
|
||||
|
||||
- `artifact`: This data type tells you information about what Packer created
|
||||
during its build. An example of output follows the pattern
|
||||
`timestamp, buildname, artifact, artifact_number, key, value` where `key`
|
||||
and `value` contain information about the artifact.
|
||||
|
||||
For example:
|
||||
|
||||
```text
|
||||
1539967803,,ui,say,\n==> Builds finished. The artifacts of successful builds are:
|
||||
1539967803,amazon-ebs,artifact-count,2
|
||||
1539967803,amazon-ebs,artifact,0,builder-id,mitchellh.amazonebs
|
||||
1539967803,amazon-ebs,artifact,0,id,eu-west-1:ami-04d23aca8bdd36e30
|
||||
1539967803,amazon-ebs,artifact,0,string,AMIs were created:\neu-west-1: ami-04d23aca8bdd36e30\n
|
||||
1539967803,amazon-ebs,artifact,0,files-count,0
|
||||
1539967803,amazon-ebs,artifact,0,end
|
||||
1539967803,,ui,say,--> amazon-ebs: AMIs were created:\neu-west-1: ami-04d23aca8bdd36e30\n
|
||||
1539967803,amazon-ebs,artifact,1,builder-id,
|
||||
1539967803,amazon-ebs,artifact,1,id,
|
||||
1539967803,amazon-ebs,artifact,1,string,
|
||||
1539967803,amazon-ebs,artifact,1,files-count,0
|
||||
2018/10/19 09:50:03 waiting for all plugin processes to complete...
|
||||
1539967803,amazon-ebs,artifact,1,end
|
||||
```
|
||||
|
||||
You'll see these data types when you run `packer version`:
|
||||
|
||||
- `version`: what version of Packer is running
|
||||
|
||||
- `version-prerelease`: Data will contain `dev` if version is prerelease, and
|
||||
otherwise will be blank.
|
||||
|
||||
- `version-commit`: The git hash for the commit that the branch of Packer is
|
||||
currently on; most useful for Packer developers.
|
||||
|
||||
## Autocompletion
|
||||
|
||||
The `packer` command features opt-in subcommand autocompletion that you can
|
||||
enable for your shell with `packer -autocomplete-install`. After doing so, you
|
||||
can invoke a new shell and use the feature.
|
||||
|
||||
For example, assume a tab is typed at the end of each prompt line:
|
||||
|
||||
```shell-session
|
||||
$ packer p
|
||||
plugin build
|
||||
$ packer build -
|
||||
-color -debug -except -force -machine-readable -on-error -only -parallel -timestamp -var -var-file
|
||||
```
|
||||
@@ -1,86 +0,0 @@
|
||||
---
|
||||
description: |
|
||||
The `packer init` command downloads and installs the plugins specified in a Packer template.
|
||||
page_title: packer init command reference
|
||||
---
|
||||
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
> [!IMPORTANT]
|
||||
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
||||
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
||||
|
||||
# `packer init` command reference
|
||||
|
||||
<Note>
|
||||
|
||||
Starting August 1st, 2025, the source for many official HashiCorp-maintained Packer plugins is moving from GitHub releases to the official HashiCorp release site, [releases.hashicorp.com](https://releases.hashicorp.com). Refer to [Install HashiCorp-maintained plugins](/packer/docs/plugins/install#install-hashicorp-maintained-plugins) for more information.
|
||||
|
||||
</Note>
|
||||
|
||||
|
||||
The `packer init` command initializes Packer according to an HCL template configuration. Refer to [Installing Plugins](/packer/docs/plugins/install) for additional information about installing plugins.
|
||||
|
||||
## Description
|
||||
|
||||
Use the `packer init` command to download and install plugins according to the `required_plugins` block in Packer templates written in HCL. Refer to [Specifying plugin requirements](/packer/docs/templates/hcl_templates/blocks/packer#specifying-plugin-requirements) in the template configuration reference for additional information about configuring the `required_plugins` block.
|
||||
|
||||
Legacy JSON templates are not supported. You can convert your JSON template files to HCL using the [hcl2_upgrade](/packer/docs/commands/hcl2_upgrade) command.
|
||||
|
||||
We recommend running the `packer init` command as the first step when working with a new or existing template. You can run the command multiple times. Subsequent runs may produce errors, but the command never deletes already-installed plugins.
|
||||
|
||||
### Third-party plugin verification
|
||||
|
||||
We recommend that you vet and verify any third-party plugins you want to install.
|
||||
|
||||
### Installation location
|
||||
|
||||
By default, Packer installs plugins into the plugins directory at `$HOME/.config/packer/plugins` on Unix and `%APPDATA%\packer.d\plugins` on Windows, but you can specify a different directory using the `PACKER_PLUGIN_PATH` environment variable. Refer to the [Packer configuration reference](/packer/docs/configure) for additional information.
|
||||
|
||||
## Usage
|
||||
|
||||
Use the following syntax to run the `packer init` command:
|
||||
|
||||
```shell-session
|
||||
$ packer init <path-to-template>
|
||||
```
|
||||
The command will process any template file that ends with `pkr.hcl`.
|
||||
|
||||
The template must contain all dependencies when running the command on a single template file. The command fails if the template is intended to be built as a bundle of partials.
|
||||
|
||||
For variable definitions, it is recommended to use the extensions `.pkrvars.hcl` or `.auto.pkrvars.hcl`. When you run `packer init` in the directory, these variable definition files will be automatically excluded from processing.
|
||||
|
||||
## Examples
|
||||
|
||||
The following example installs the plugins specified in a template from the current directory:
|
||||
|
||||
```shell-session
|
||||
$ packer init .
|
||||
```
|
||||
|
||||
The following example installs the plugins specified in a template named `template.pkr.hcl` from the current directory:
|
||||
```shell-session
|
||||
$ packer init template.pkr.hcl
|
||||
```
|
||||
|
||||
The following example installs the plugins specified in the `builds/foo/` directory:
|
||||
|
||||
```shell-session
|
||||
$ packer init builds/foo/.
|
||||
```
|
||||
|
||||
The following example installs the plugins specified in a template from the `builds/foo/template.pkr.hcl` path:
|
||||
|
||||
```shell-session
|
||||
$ packer init builds/foo/template.pkr.hcl
|
||||
```
|
||||
|
||||
## Arguments
|
||||
|
||||
You can pass the following arguments:
|
||||
|
||||
- Packer template: Specify the path to either an HCL2 template or a directory containing at least one valid HCL2 template and related dependencies.
|
||||
|
||||
## Options
|
||||
|
||||
- `-upgrade`: Use this option to upgrade plugins that are already installed to the latest available version. Packer upgrades to the latest version in accordance with the version constraints specified in the template.
|
||||
- `-force`: Use this option to force Packer to reinstall plugins.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user