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).

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 -D|--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.
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)

Assets 3

28 Mar 07:36

genesis-bot

v2.8.5

91feeb6

v2.8.5

Improvements

Added genesis lookup --env to retrieve environment variable values
used by Genesis for the specified environment. Like all lookup
commands, '.' will return everything in JSON format, single value will
be returned as an unquoted string, and default if specified, will be
returned if environment variable specified doesn't exist.
Added --no-bosh and --no-vault to genesis env-shell command, so
that you can access a shell without forcing connections to those
services.
Fixed output of genesis env-shell so that the preamble header
doesn't go to stdout. This better allows running a user-provided
executable as a shell (--shell path/to/executable option) to run
arbitrary commands inside "Genesis-space", then capturing its output.
Added -p|--pre flag to genesis update to allow checking for or
upgrading to prereleases.
genesis decompile-kit can now take just the kit name or version.
Specifying the name will decompile the latest local version, and
specifying the version doesn't need the kit name if its unambiguous.
The version can handle the v prefix in genesis decompile-kit
You can specify latest as the argument if only one kit type is in
use (which is the way Genesis is designed to function)
Show the version of Genesis when doing a deploy; helps with diagnoses
when user submits deploy output when encountering an error.

Bug Fixes

Ignore any 'v' prefix when specifying the version in genesis compile-kit
Fixes issues encountered when creating new environments based on the
bosh Genesis kit. This also removed the confusing bosh_env: --
entry under genesis in environment yml files.
Future-proofing for creating new environments based on
bosh-genesis-kit v3.0.0 (--[no-]create-env option to genesis new)
Improved error messages for create-env/bosh_env conflicts.
genesis new now supports environment-first call style, allowing
users to type genesis <env> new ... to create the new environment.
Fixes another issue with genesis new when genesis bosh --connect
has been used in the terminal session.
genesis new will explicitly prune genesis.bosh_env when making a
new create-env based (aka proto) environment.
When preparing exodus data after deploy, properly handle undefined
values.
The genesis bosh command now runs in the users calling directory, so
relative paths to files work as expected.
Fixed bug where some systems could not validate SSH keys due to
permission issues with here-strings.