Improvements

Clarified create-kit help description regarding the -n option to indicate
that it automatically adds "-genesis-kit" suffix
The generated scaffolding now has the base manifest default to use bionic stemcells
genesis bosh now supports all the basic options, including
--[no-]color, -q|--quiet, -D|--debug, -T|--trace, and -S|--show-stack.
Add the yaml files used during the check process of deployment. This
is especially useful when running deployments in pipelines, and when
running the spec tests. To enable it, set the environment variable
GENESIS_CHECK_YAML_ON_DEPLOY to a truthy value (1, yes, true, Y) and
export it (or set it in params section of the deploy task).
Add pre-deploy and post-deploy reactions on a per-environment basis.

Sometimes different environments need to perform tasks prior to and
after doing a deploy. This feature allows you to specify scripts that
will be run in those circumstances. Add the following structure to
your environment file:
```
genesis:
  reactions:
    pre-deploy:
      - script: put-up-maintenance-page
      - script: update-jira
        args:   [ 'some-argument', '$SOME_ENV_VAR' ]
    post-deploy:
      - addon: valid-addon-for-kit
      - script: remove-maintenance-page
```
The scripts are located in the bin/ dir under the repository root
directory, and are propagated via the pipeline cache system.

The scripts have access to the following environment variables:
- GENESIS_PREDEPLOY_DATAFILE -- file path that contains any data
  gathered by the predeploy hook
- GENESIS_MANIFEST_FILE -- file path to the full unredacted unpruned
  manifest for the current deployment
- GENESIS_BOSHVARS_FILE -- file path to any BOSH variables for the
  deployment
- GENESIS_DEPLOY_OPTIONS -- JSON representation of the options passed
  to the deploy call
- GENESIS_DEPLOY_DRYRUN -- "true" if the deployment is a dry-run,
  "false" otherwise
- GENESIS_DEPLOY_RC -- return code of the BOSH deploy call. 0 if
  successful, 1 otherwise. Only available for post-deploy reactions
You can now specify where your alternative BOSH director's credentials
can be found.

By convention, your BOSH environment (the director you are using to
deploy your environment) is the same name as the environment you are
deploying, and its credentials are stored in exodus in the same
vault.

This isn't possible when what you're deploying is another BOSH
director, so Genesis has always made it possible to specify another
BOSH environment alias, via the genesis.bosh_env parameter, and
before that, via the params.bosh in the bosh kit.

Furthermore, if you deployed your BOSH director with a non-standard
kit, you could specify that deployment-type as such:
<alias>/<deployment-type>. By default, that deployment type is
bosh

When v2.8.0 came around, we started storing access for the credentials
to the BOSH director in vault. While we always recommend using a
single vault for all deployments in your deploy repo, some companies
have policies that don't allow that. To this end, you can now specify
which vault and exodus base path under which your BOSH director
credentials can be found. This extends genesis.bosh_env with the
following pattern:
```
<alias>[/<deployment-type>][@[http(s?)://<host>[:<port]/]<base-path>]
```
We still recommend a single vault and single exodus base path whenever
possible, as most of the existing kits that use exodus data do not
have the ability to specify an alternative vault or path. This simply
allows the layering of nested BOSHes to work within the confines of
corporate security policies.
Adds a --fix-releases option to deployment for when you need to re-upload
a bosh release. This is rarely needed, mainly if you change the underlying
stemcell to a new OS.
Support --recreate-persistent-disks on deploy for both deploy and
create-env environments.
genesis decompile-kit will now accept file with .yml suffix

Kit Authoring Improvements

Added print_addon_descriptions and run_extended_addon helpers to
support extended addon scripts.

Rather than have all the addons in the hooks/addon file, you can add
individual hook/addon-<name>~<shortcut>. To do so, you need to
follow the following conventions:
- The script gets passed as its first argument the action to take.
  This is either help or run. Help prints out the description to be
  used in list, and run causes the script to run.
- The main hooks/addon script must use print_addon_descriptions in its
  list command block, with alternative arguments of the base commands
  and descriptions. Example:
```
list) print_addon_descriptions \
        "command" "description of command" \
        "another" "description of another command" ;;
```
- The main hook/addon script uses run_extended_addon as its catch-all
  *) block.
You can now find more genesis environment information in the manifest.
In addition to the existing keys under genesis., you can now find
the vaultified environment (dashes into slashes) in
genesis.vault_env, and the full path for the secrets and exodus
base: genesis.secrets_base and genesis.exodus_base respectively.
genesis.secrets_base is the same value as meta.vault but with the
trailing /.

Bug Fixes

When using legacy secrets provider, if the current safe target has the
same URL as another safe target, a confusing error would be printed.
This change provides a much more informative error message.
When using a specified secrets provider for a deployment repo, a more
instructive error message is provided when multiple safe targets with
the same URL is specified.
Genesis doesn't like the https_proxy or HTTPS_PROXY environment
variables being set, but BOSH was happy when they were set to "".
However, upstream BOSH now considers that an error, so Genesis is
going to simply unset them.

If you need to use HTTPS proxy, you can still set GENESIS_HONOR_ENV
to a truthy value, and it will keep HTTPS_PROXY and https_proxy
environment variables from the calling scope, but only do this if
you encounter an error.
No longer errors when running genesis version if prerequisites are
missing (the lone exception of course is if perl itself is missing)
Clearing of the secrets provider (genesis secrets-provider --clear)
now works. This puts genesis in "Legacy Mode", meaning it will use
whatever your current safe target is as the source for your genesis
secrets. Not recommended, but there are specific use cases that
required it (for now).
Support --recreate for create-env environments. This was already
supported for deploy-based environments, but was erroneously denied
for create-env based environments (ie proto-bosh)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improvements

Kit Authoring Improvements

Bug Fixes

Releases: genesis-community/genesis

v2.8.7-rc.4

v2.8.7-rc.3

v2.8.6

Improvements

Kit Authoring Improvements

Bug Fixes

v2.8.6-rc.17

v2.8.6-rc.16

v2.8.6-rc.15

v2.8.6-rc.13

v2.8.6-rc.11

v2.8.6-rc.10

v2.8.6-rc.9