ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/scripts/docker-release/README.md

78 lines
2.9 KiB
Markdown
Raw Normal View History

build: configuration for building "release" docker images These are different than our "full" images because they include a binary already released to releases.hashicorp.com, whereas the root Dockerfile directly builds from the current work tree. This particular Dockerfile is not intended to be run manually, but rather exists only to drive the dockerhub automated build.
2017-07-19 21:59:13 +02:00
# Terraform Docker Release Build
build: scripted local build process for docker images #15596 set things up with the intent that the docker image build process would be handled by the automated build system on dockerhub, but after merging we found that it's impossible to change the source git repository for an existing dockerhub repository. To get away from the limitations of dockerhub, we intend to eventually automate these builds in a separate CI system. Here we add some scripts that would drive such an automated process. It's split into multiple steps to allow for situations where the new version should not be tagged as the latest, and to make it easier and safer to test the build script while doing development on it. Since this automated process doesn't yet exist, a wrapper script release.sh is included to help run a local, manual build and deploy process in the mean time. The README.md in the docker-release dir here contains details on the intended usage.
2017-07-29 02:30:42 +02:00
This directory contains configuration to drive the docker image releases for
Terraform.
build: configuration for building "release" docker images These are different than our "full" images because they include a binary already released to releases.hashicorp.com, whereas the root Dockerfile directly builds from the current work tree. This particular Dockerfile is not intended to be run manually, but rather exists only to drive the dockerhub automated build.
2017-07-19 21:59:13 +02:00
build: scripted local build process for docker images #15596 set things up with the intent that the docker image build process would be handled by the automated build system on dockerhub, but after merging we found that it's impossible to change the source git repository for an existing dockerhub repository. To get away from the limitations of dockerhub, we intend to eventually automate these builds in a separate CI system. Here we add some scripts that would drive such an automated process. It's split into multiple steps to allow for situations where the new version should not be tagged as the latest, and to make it easier and safer to test the build script while doing development on it. Since this automated process doesn't yet exist, a wrapper script release.sh is included to help run a local, manual build and deploy process in the mean time. The README.md in the docker-release dir here contains details on the intended usage.
2017-07-29 02:30:42 +02:00
Two different types of image are produced for each Terraform release:
build: configuration for building "release" docker images These are different than our "full" images because they include a binary already released to releases.hashicorp.com, whereas the root Dockerfile directly builds from the current work tree. This particular Dockerfile is not intended to be run manually, but rather exists only to drive the dockerhub automated build.
2017-07-19 21:59:13 +02:00
build: scripted local build process for docker images #15596 set things up with the intent that the docker image build process would be handled by the automated build system on dockerhub, but after merging we found that it's impossible to change the source git repository for an existing dockerhub repository. To get away from the limitations of dockerhub, we intend to eventually automate these builds in a separate CI system. Here we add some scripts that would drive such an automated process. It's split into multiple steps to allow for situations where the new version should not be tagged as the latest, and to make it easier and safer to test the build script while doing development on it. Since this automated process doesn't yet exist, a wrapper script release.sh is included to help run a local, manual build and deploy process in the mean time. The README.md in the docker-release dir here contains details on the intended usage.
2017-07-29 02:30:42 +02:00
* A "light" image that includes just the release binary that should match
what's on releases.hashicorp.com.
build: configuration for building "release" docker images These are different than our "full" images because they include a binary already released to releases.hashicorp.com, whereas the root Dockerfile directly builds from the current work tree. This particular Dockerfile is not intended to be run manually, but rather exists only to drive the dockerhub automated build.
2017-07-19 21:59:13 +02:00
build: scripted local build process for docker images #15596 set things up with the intent that the docker image build process would be handled by the automated build system on dockerhub, but after merging we found that it's impossible to change the source git repository for an existing dockerhub repository. To get away from the limitations of dockerhub, we intend to eventually automate these builds in a separate CI system. Here we add some scripts that would drive such an automated process. It's split into multiple steps to allow for situations where the new version should not be tagged as the latest, and to make it easier and safer to test the build script while doing development on it. Since this automated process doesn't yet exist, a wrapper script release.sh is included to help run a local, manual build and deploy process in the mean time. The README.md in the docker-release dir here contains details on the intended usage.
2017-07-29 02:30:42 +02:00
* A "full" image that contains all of the Terraform source code and a binary
built from that source.
build: configuration for building "release" docker images These are different than our "full" images because they include a binary already released to releases.hashicorp.com, whereas the root Dockerfile directly builds from the current work tree. This particular Dockerfile is not intended to be run manually, but rather exists only to drive the dockerhub automated build.
2017-07-19 21:59:13 +02:00
build: scripted local build process for docker images #15596 set things up with the intent that the docker image build process would be handled by the automated build system on dockerhub, but after merging we found that it's impossible to change the source git repository for an existing dockerhub repository. To get away from the limitations of dockerhub, we intend to eventually automate these builds in a separate CI system. Here we add some scripts that would drive such an automated process. It's split into multiple steps to allow for situations where the new version should not be tagged as the latest, and to make it easier and safer to test the build script while doing development on it. Since this automated process doesn't yet exist, a wrapper script release.sh is included to help run a local, manual build and deploy process in the mean time. The README.md in the docker-release dir here contains details on the intended usage.
2017-07-29 02:30:42 +02:00
The latter can be produced for any arbitrary commit by running `docker build`
in the root of this repository. The former requires that the release archive
already be deployed on releases.hashicorp.com.
build: configuration for building "release" docker images These are different than our "full" images because they include a binary already released to releases.hashicorp.com, whereas the root Dockerfile directly builds from the current work tree. This particular Dockerfile is not intended to be run manually, but rather exists only to drive the dockerhub automated build.
2017-07-19 21:59:13 +02:00
build: scripted local build process for docker images #15596 set things up with the intent that the docker image build process would be handled by the automated build system on dockerhub, but after merging we found that it's impossible to change the source git repository for an existing dockerhub repository. To get away from the limitations of dockerhub, we intend to eventually automate these builds in a separate CI system. Here we add some scripts that would drive such an automated process. It's split into multiple steps to allow for situations where the new version should not be tagged as the latest, and to make it easier and safer to test the build script while doing development on it. Since this automated process doesn't yet exist, a wrapper script release.sh is included to help run a local, manual build and deploy process in the mean time. The README.md in the docker-release dir here contains details on the intended usage.
2017-07-29 02:30:42 +02:00
## Build and Release
build: documentation for the new docker image release process At the time of commit this file contains some things that are not yet true due to the dockerhub configuration not having been updated. This therefore remains aspirational until merged, after which the docherhub configuration will be updated.
2017-07-19 22:02:39 +02:00
build: scripted local build process for docker images #15596 set things up with the intent that the docker image build process would be handled by the automated build system on dockerhub, but after merging we found that it's impossible to change the source git repository for an existing dockerhub repository. To get away from the limitations of dockerhub, we intend to eventually automate these builds in a separate CI system. Here we add some scripts that would drive such an automated process. It's split into multiple steps to allow for situations where the new version should not be tagged as the latest, and to make it easier and safer to test the build script while doing development on it. Since this automated process doesn't yet exist, a wrapper script release.sh is included to help run a local, manual build and deploy process in the mean time. The README.md in the docker-release dir here contains details on the intended usage.
2017-07-29 02:30:42 +02:00
The scripts in this directory are intended for running the steps to build,
tag, and push the two images for a tagged and released version of Terraform.
They expect to be run with git `HEAD` pointed at a release tag, whose name
is used to determine the version to build. The version number indicated
by the tag that `HEAD` is pointed at will be referred to below as
the _current version_.
build: documentation for the new docker image release process At the time of commit this file contains some things that are not yet true due to the dockerhub configuration not having been updated. This therefore remains aspirational until merged, after which the docherhub configuration will be updated.
2017-07-19 22:02:39 +02:00
build: scripted local build process for docker images #15596 set things up with the intent that the docker image build process would be handled by the automated build system on dockerhub, but after merging we found that it's impossible to change the source git repository for an existing dockerhub repository. To get away from the limitations of dockerhub, we intend to eventually automate these builds in a separate CI system. Here we add some scripts that would drive such an automated process. It's split into multiple steps to allow for situations where the new version should not be tagged as the latest, and to make it easier and safer to test the build script while doing development on it. Since this automated process doesn't yet exist, a wrapper script release.sh is included to help run a local, manual build and deploy process in the mean time. The README.md in the docker-release dir here contains details on the intended usage.
2017-07-29 02:30:42 +02:00
* `build.sh` builds locally both of the images for the current version.
This operates on the local docker daemon only, and produces tags that
include the current version number.
build: documentation for the new docker image release process At the time of commit this file contains some things that are not yet true due to the dockerhub configuration not having been updated. This therefore remains aspirational until merged, after which the docherhub configuration will be updated.
2017-07-19 22:02:39 +02:00
build: scripted local build process for docker images #15596 set things up with the intent that the docker image build process would be handled by the automated build system on dockerhub, but after merging we found that it's impossible to change the source git repository for an existing dockerhub repository. To get away from the limitations of dockerhub, we intend to eventually automate these builds in a separate CI system. Here we add some scripts that would drive such an automated process. It's split into multiple steps to allow for situations where the new version should not be tagged as the latest, and to make it easier and safer to test the build script while doing development on it. Since this automated process doesn't yet exist, a wrapper script release.sh is included to help run a local, manual build and deploy process in the mean time. The README.md in the docker-release dir here contains details on the intended usage.
2017-07-29 02:30:42 +02:00
* `tag.sh` updates the `latest`, `light` and `full` tags to refer to the
images for the current version, which must've been already produced by
an earlier run of `build.sh`. This operates on the local docker daemon
only.
build: documentation for the new docker image release process At the time of commit this file contains some things that are not yet true due to the dockerhub configuration not having been updated. This therefore remains aspirational until merged, after which the docherhub configuration will be updated.
2017-07-19 22:02:39 +02:00
build: scripted local build process for docker images #15596 set things up with the intent that the docker image build process would be handled by the automated build system on dockerhub, but after merging we found that it's impossible to change the source git repository for an existing dockerhub repository. To get away from the limitations of dockerhub, we intend to eventually automate these builds in a separate CI system. Here we add some scripts that would drive such an automated process. It's split into multiple steps to allow for situations where the new version should not be tagged as the latest, and to make it easier and safer to test the build script while doing development on it. Since this automated process doesn't yet exist, a wrapper script release.sh is included to help run a local, manual build and deploy process in the mean time. The README.md in the docker-release dir here contains details on the intended usage.
2017-07-29 02:30:42 +02:00
* `push.sh` pushes the current version tag and the `latest`, `light` and
`full` tags up to dockerhub for public consumption. This writes images
to dockerhub, and so it requires docker credentials that have access to
write into the `hashicorp/terraform` repository.
### Releasing a new "latest" version
In the common case where a release is going to be considered the new latest
stable version of Terraform, the helper script `release.sh` orchestrates
all of the necessary steps to release to dockerhub:
```
$ git checkout v0.10.0
$ scripts/docker-release/release.sh
```
Behind the scenes this script is running `build.sh`, `tag.sh` and `push.sh`
as described above, with some extra confirmation steps to verify the
correctness of the build.
This script is interactive and so isn't suitable for running in automation.
For automation, run the individual scripts directly.
### Releasing a beta version or a patch to an earlier minor release
The `release.sh` wrapper is not appropriate in two less common situations:
* The version being released is a beta or other pre-release version, with
a version number like `v0.10.0-beta1` or `v0.10.0-rc1`.
* The version being released belongs to a non-current minor release. For
example, if the current stable version is `v0.10.1` but the version
being released is `v0.9.14`.
In both of these cases, only the specific version tag should be updated,
which can be done as follows:
```
$ git checkout v0.11.0-beta1
$ scripts/docker-release/build.sh
$ docker push hashicorp/terraform:0.11.0-beta1
```