Tag Git on every successful release
Escape already used to compile Git metadata into a release so that each Escape release could be related back to a commit, but now you can also relate commits back to Escape releases.
Git tagging is not enabled by default, but needs to be explicitly set as an
argument on the “release” command.
escape run release --tag-git tags the
current git commit with the full release ID, but it does not try and push these
escape run release --tag-git --push-git-tags: tags the
current git commit with the full release ID and also pushes the tags to the git
Provider Activation and Deactivation
Providers and consumers provide a nice pattern to decouple platform
dependencies, and they just became a lot more powerful with the introduction of
two new Escape Plan fields:
two script fields can be defined in the provider’s plan and will be run
whenever a deployment consumes it. For example: if my application consumes a
kubernetes release, we can now define Kubernetes related scripts that need to
be run before and after I do my application deployment (to manage credentials for
example). Here are a few more examples of things you can do:
- Activate and deactive VPN connections
- Activate and deactive CLI tools (e.g.
docker login, etc.)
- Activate and deactive credentials
One of the bigger changes in Escape lately has been the ability to release packages without having to run an Inventory server process. This new local Inventory is enabled by default and makes it easier for people to get started with Escape: just get the binary and you’re good to go:
curl -L https://www.ankyra.io/install_escape.sh | bash
It is still possible and even desirable to run the Inventory as a server process when working within a team or when using Escape as part of a CI/CD pipeline, but it is very well suited for local development; especially with the ability to pull only some namespaces from a remote Inventory and get the rest locally.