2017-05-19 15:01:01 +00:00
|
|
|
---
|
|
|
|
|
layout: "docs"
|
|
|
|
|
page_title: "API Release Workflow"
|
|
|
|
|
sidebar_current: "vagrant-cloud-boxes-release-workflow"
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# API Release Workflow
|
|
|
|
|
|
2017-05-19 16:34:03 +00:00
|
|
|
Creating new boxes through their [release lifecycle](/docs/vagrant-cloud/boxes/lifecycle.html)
|
2017-05-19 15:24:04 +00:00
|
|
|
is possible through the Vagrant Enterprise website, but you can also automate
|
|
|
|
|
the task via the Vagrant Enterprise API.
|
2017-05-19 15:01:01 +00:00
|
|
|
|
|
|
|
|
1. Create box, or locate a boxes `tag`, like `hashicorp/precise64`
|
|
|
|
|
2. After some event, like the end of a CI build, you may want to
|
|
|
|
|
release a new version of the box. To do this, first use the API to
|
|
|
|
|
create a new version with a version number and a short description
|
|
|
|
|
of the changes
|
|
|
|
|
3. Then, create any providers associated with the version, like
|
|
|
|
|
`virtualbox`
|
|
|
|
|
4. Once your system has made the necessary requests to the API and the
|
|
|
|
|
version is ready, make a request to the `release` endpoint on the version
|
|
|
|
|
5. The version should now be available to users of the box via
|
|
|
|
|
the command `vagrant box outdated` or via the automated checks on
|
|
|
|
|
`vagrant up`
|
