v5.2.1

v5.2.1

This release fixes a bug identified by @dmccaffery. If a repository had no CI checks defined and and PR was approved, then no conditions would be met and branch-deploy would not continue.

Additional Changes:

• Updating Actions workflows
• Updating all node packages

What's Changed

• Upgrade yaml validation by @GrantBirki in #140
• Update Documentation by @GrantBirki in #141
• CI Status Check Fixes by @GrantBirki in #142

Full Changelog: v5.2.0...v5.2.1

v5.2.0

v5.2.0

What's Changed

• More docs updates by @GrantBirki in #136
• no trigger detected log by @GrantBirki in #137
• General Repo Updates by @GrantBirki in #138
• Action Config Validation by @GrantBirki in #139

Full Changelog: v5.1.1...v5.2.0

v5.1.1

v5.1.1

This release fixes a bug where the log_url in deployment statuses was not being properly set.

This release also updates documentation, update Actions workflows in our CI, and adds new docs examples using Astro.

What's Changed

• Fix log_url in deployment status by @sinsoku in #132
• Add non-sticky lock removal to the example by @sinsoku in #133
• Examples Docs Updates by @GrantBirki in #134
• Update all Actions Workflows by @GrantBirki in #135

Full Changelog: v5.1.0...v5.1.1

v5.1.0

v5.1.0

Introducing environment_urls with deployments! 🚀

This pull request adds a new Action's input option called environment_urls. The input option is a mapping of "environments" -> "environment urls" that can be deployed.

Configuration

Explanation for the formatting of this new input option

This input option is a mapping of environment names to URLs and the environment names must match the environment_targets input option. This option is a comma separated list with pipes (|) separating the environment from the URL.

Note: disabled is a special keyword to disable an environment url if you enable this option but not all environments have a url.

Format: "<environment1>|<url1>,<environment2>|<url2>,etc"

Example: "production|https://myapp.com,development|https://dev.myapp.com,staging|disabled"

This option is especially useful when your deployment targets are services with a URL (website, API, etc)

By enabling this option, you will get a "clickable" link on success (non-noop) deployment messages on pull requests. You will also be able to click the "View deployment" button in your repository's deployments page and be taken to the URL of the environment you deployed to.

If you wish to disable the "clickable" link on the successful deloyment message, you can set the environment_url_in_comment input to "false".

Example Usage

If running this Action deploys a website called example.com and that deployment is run with .deploy to production, then you can setup the following mapping with this new input option like so:

- name: branch-deploy
  id: branch-deploy
  uses: github/[email protected]
  with:
    trigger: ".deploy"
    environment: "production"
    environment_targets: "production,development,staging"
    environment_urls: "production|https://example.com,development|https://dev.example.com,staging|stg.example.com"
    environment_url_in_comment: "true"

By setting up this Action, you can get "View deployment" buttons on your environment page that allow you view the URL associated with your deployment

Additionally, if a matching environment url is found for an environment and the deployment is not a noop deploy, the URL with a clickable link will be appended to the bottom of a successful deployment message:

---

What's Changed

• Test Framework Improvements 🧪 by @GrantBirki in #126
• environment_url in deployments by @GrantBirki in #128
• Environment URL Improvements by @GrantBirki in #129
• --reason (lock/unlock) bug fixes by @GrantBirki in #130
• ensure --reason is removed from unlock commands by @GrantBirki in #131

Full Changelog: v5.0.0...v5.1.0

v5.0.0

v5.0.0

Environment Specific Locks 🌍 🔒

This release enables a long requested feature, environment locks!

Why?

Currently, there is only one type of lock and it is a global lock. If a user types .lock on a pull request (with this Action), that user will be the only user that can deploy to any environment. This is effectively a global deploy lock and can be quite hindering to teams with multiple deployment environments. For example, if user A comments .lock because they are doing a deployment to production, then user B cannot request a deployment to staging until the deployment lock is removed. This is less than ideal, and this pull request puts all that in the past

How?

The .lock mechanism in this Action is kind of a "neat hack" and has been since its first inception. There isn't really an ideal way of preserving state between two separate Actions. I thought it might be creative to see what sort of atomic operations exist on GitHub and found that a branch push is about the closest you can get. That is what the .lock mechanism first used and still uses with these changes. The main change though, is instead of all locks storing data in a single (kind of global) branch called branch-deploy-lock, it is now multiple branches -> <environment|global>-branch-deploy-lock. This allows for separate environments to be locked on their own and even support a new option for "globally" locking all environments in the project/repository

New Input Option 🆕

This pull request also adds a new input option for this Action -> global_lock_flag: <string>

The global_lock_flag is an optional input and defaults to --global. User's can pass in --global to lock/unlock command to set or remove a global lock which will block all available options.

Example: .lock --reason a major production incident is being investigated --global

Usage 💻

This section documents the new .lock, .unlock, and .wcid information:

.wcid is the shorthand alias for .lock --details - It means "where can I deploy"

• .lock - locks the default environment
• .lock <environment> - locks the designated environment
• .unlock - unlocks the default environment
• .unlock <environment> - unlocks the designated environment
• .lock --global - Where --global is a string set by the user's config. If present, it locks all environments
• .unlock --global - Where --global is a string set by the user's config. If present, it unlocks all environments
• .wcid - checks if there is a deploy lock on the default environment
• .wcid <environment> - checks if there is a deploy lock on the designated environment

It should be noted that if you use any commands such as .lock, .unlock, .lock --details, .wcid, etc without a specified environment, then they will use the whatever environment you have configured as the default in your Action's inputs. This value is usually production and you can see its definition here

Examples 📷

Here are some examples using these new options:

Lock

• .lock <environment>
  • .lock production - Locks the production environment
  • .lock development - Locks the development environment
  • .lock production --reason something is broken -- Locks the production environment with a "reason"
  • .lock --global - Globally lock all available environments (--reason <text> works here too!)

Unlock

• .unlock <environment>
  • .unlock production - Unlocks the production environment
  • .unlock development - Unlocks the development environment
  • .unlock --global - Globally unlock all available environments

Lock Details

• .lock <environment> --details
  • .lock --details production - Check to see if there is a production lock and return it's details if it exists
  • .lock --details - Check to see if there is a "default environment" lock and return it's details if it exists
  • .lock --global --details - Check to see if there is a "global" lock and return it's details if it exists
  • .wcid <blank|environment|--global> - Shorthand alias for getting lock details

Note: .lock -d, .lock --details, .lock --d, .lock --info, .lock -i, .lock --i, and .wcid all do the same thing - source

Example Screenshots 📸

Cannot deploy due to a global deploy lock:

Locks now match useable environments:

Locks details now tell you have to "unlock" the lock that is blocking you:

---

Additional Changes

This pull request has additional changes backed into it as well!

• Improved unit tests throughout the code base
• Improved comment output onto pull requests created by this Action
• Minor bug fixes
• Improved documentation

⚠️ Breaking Changes

It should be noted that all existing locks for a project should be removed before upgrading to this release or you may have unexpected locking behavior.

What's Changed

• Environment Specific Locks 🌍 🔒 by @GrantBirki in #120
• Lock Link Fixes by @GrantBirki in #123
• HAS_HOOKS checks by @GrantBirki in #124

Full Changelog: v4.6.1...v5.0.0

v4.6.1

v4.6.1

What's Changed

• Bug Template by @GrantBirki in #118
• Add auto_merge option for GitHub create a deployment API by @GrantBirki in #121 - coauthored by @kyo-nanba

Full Changelog: v4.6.0...v4.6.1

v4.6.0

v4.6.0

This release adds sha as a new output from this Action. The sha will always be present on the following types of interactions:

• .deploy noop - noop deploys
• .deploy - standard deploys
• .deploy main - rollback deploys

What's Changed

• Add sha to Action outputs by @GrantBirki in #116

Full Changelog: v4.5.2...v4.6.0

v4.5.2

v4.5.2

What's Changed

• Add sha to outputs by @sinsoku in #114

Full Changelog: v4.5.1...v4.5.2

v4.5.1

v4.5.1

Adding better support for users on GHES by using environment variables to find the GitHub server URL rather than hardcoding https://github.com

What's Changed

• GHES Support by @GrantBirki in #111
• Server URL Fixes by @GrantBirki in #112

Special Thanks

Thanks to @KevinMSampson for raising attention around GHES support.

Full Changelog: v4.5.0...v4.5.1

v4.5.0

v4.5.0

What's Changed

• Add Additional Outputs by @GrantBirki in #106

Full Changelog: v4.4.1...v4.5.0