Pantheon release notes

Sites on the Next Generation GCDN can now exempt their own trusted automation from bot protection, without contacting support.

Bot protection on the Next Generation GCDN automatically challenges traffic that looks automated. That is the right default for scrapers and attack tools, but it can also challenge automation you rely on: uptime monitors, CI/CD pipelines, feed importers, and custom API clients that are not on the verified bot list.

You can now generate a bot bypass token for your site using Terminus and configure your automation to send it in the x-pantheon-bot-bypass request header. Requests carrying a valid token skip the standard challenge applied to automated traffic; targeted protections, rate limiting, and the managed WAF still apply to every request.

Key details:

• Tokens are scoped to a single site (all environments) and valid for 6 months. The command returns a current token and a next token that becomes valid 3 months later; both are accepted during the overlap. Send the current token now, switch to the next token on or after its start date, and re-run the command each quarter to pick up the following pair.
• Treat the token like a credential. Send it only from trusted servers and services, and never expose it in client-side code. If a token is leaked, contact Pantheon support to revoke it; a replacement token becomes available at the start of the following month.
• Requests without the header are evaluated by bot protection as usual. Requests with an incorrect token are rejected with a 403, so check the header value first if your automation starts failing.

See Bot Bypass Tokens in the Next Generation GCDN guide for setup instructions.

Version 0.9.5 of the 'Push to Pantheon' GitHub Action is now available. This release changes how the action handles a push that has no Pantheon environment to deploy to, and corrects the documentation for the target_env and target_env_strategy inputs.

What's new

A Multidev comes from a pull request. A push to any other branch has nothing to derive an environment name from.

In 0.9.4 the action treated that as an error and failed the job, so adding the action to a workflow that runs on every push would fail on a feature branch with no PR. In 0.9.5 the action skips the remaining steps and the job succeeds, and the step log records why the deployment was skipped.

A misconfiguration still fails the job: a target_env value Pantheon will not accept, an unrecognized target_env_strategy, or the branch strategy with no branch to read.

If you want pushes to other branches to deploy, set target_env_strategy: branch to deploy to a Multidev named after the branch, or set target_env explicitly. (#188)

How to upgrade to 0.9.5

Update your workflow file to use 0.9.5:

For more information about this release, see the GitHub release page. To learn more about deploying to Pantheon from GitHub, see GitHub Actions.

If you have questions or concerns about the action, please use the Push to Pantheon issue queue.

Version 0.9.4 of the 'Push to Pantheon' GitHub Action is now available. This release fixes a command injection issue in the git_commit_message parameter, adds branch-based Multidev naming, and lets you name the GitHub deployment environment separately for each site.

Action required

Versions 0.9.0 through 0.9.3 interpolated the git_commit_message value into a shell string and evaluated it, so shell metacharacters in the message ran as commands rather than being passed as text. Arbitrary commands, passed through the git_commit_message could run on the GitHub Actions runner, which holds your PANTHEON_MACHINE_TOKEN and PANTHEON_SSH_KEY.

Only workflows that pass text into git_commit_message that someone else could control (e.g. via a PR title or branch name) are affected, and only on a site that has a Live environment and the workflow does not set skip_build_tools: true (e.g. uses the default behavior). The commit message the action generates on its own by default contains no such text, so default configurations are not affected. Versions earlier than 0.9.0 pass the message as a single quoted argument and are also unaffected.

Upgrade to 0.9.4 as soon as possible. If you cannot upgrade immediately, ensure you are not passing untrusted text into git_commit_message.

Reported by @ndewhurst. (#175)

Additional key improvements in this release

• Branch-based Multidev naming: Set target_env_strategy: branch to name the Multidev after your branch instead of pr-[NUMBER]. Branch names are normalized to satisfy Pantheon's naming rules — lowercased, unusable characters folded to hyphens, and trimmed to 11 characters — and a digit is appended when another branch already holds that name. (#183)
• Per-site GitHub deployment environments: Set deployment_environment to name the GitHub deployment environment separately from the Pantheon environment. Without it, a branch that deploys to several Pantheon sites reports every deployment under the same name, so only the most recent one stays visible in the pull request timeline. (#182)
• Multiline commit messages: git_commit_message now accepts multiline values, so you can pass Git trailers such as Source-Commit: to record where a deployment came from. (#175)
• More reliable Multidev cleanup: delete_old_environments: true now removes environments for closed pull requests that Terminus Build Tools misses. Build Tools stops paginating after roughly 200 pull requests, so environments for older closed pull requests remained until the site reached its Multidev limit. (#174)
• Multidev limit reported for named environments: The Multidev limit check now runs when you set target_env explicitly. Previously it ran only for automatically derived names, so a deployment to a named environment failed inside Terminus instead of reporting the limit. (#176)

Changes to existing behavior

target_env is now validated against Pantheon's environment naming rules. A value Pantheon would reject (uppercase letters, underscores, more than 11 characters, or a reserved name such as master) now fails immediately with an explanation instead of failing later in Terminus.

How to upgrade to 0.9.4

Update your workflow file to use 0.9.4:

For more information about this release, visit the GitHub release page (https://github.com/pantheon-systems/push-to-pantheon/releases/tag/0.9.4). To learn more about deploying to Pantheon from GitHub, see GitHub Actions (/github-actions).

If you have questions or concerns about the action, please use the 'Push to Pantheon' issue queue (https://github.com/pantheon-systems/push-to-pantheon/issues).

Pantheon's GitLab support for external repositories is now generally available to everyone directly from the Pantheon Dashboard, alongside GitHub and Pantheon-hosted Git.

What's new

• Dashboard support — When creating a new site, choose GitLab as your code host right alongside GitHub and Pantheon's integrated Git repository — no Terminus required.
• Self-hosted GitLab — Connect to GitLab.com or your own self-hosted GitLab instance.
• Token-based authentication — Authenticate using a personal access token or group access token with api and write_repository scopes.

Where to find it

During site creation, select GitLab on the Where will your code be hosted? screen to connect your repository.

For full setup instructions, see the related documentation.

The GCDN Terminus plugin now supports HTTP-01 certificate validation as an alternative to DNS TXT records when verifying domains on the next-generation Global CDN.

Certificate validation uses DNS-01 (TXT record) by default, letting your certificate be issued before you update DNS. If you'd rather not add a second TXT record for the certificate, you can now use HTTP-01 instead: once your one domain-ownership TXT record verifies, point DNS and the certificate issues over HTTP on that hostname. The certificate can't be pre-provisioned this way, so there may be brief downtime during cutover:

For full setup steps, see the Terminus CLI tab in Next Generation Global CDN.

Terminus 4.3.3 is now available. This release adds a rollbackable column to node:builds:list, a new site_admin role, and automatic session token refresh for long-running commands, along with several bug fixes.

Key improvements in this release

• rollbackable column for node:builds:list: Surfaces which builds are still eligible for rollback, so you can see rollback eligibility without a separate call. (#2903)
• New site_admin role: Adds support for the site_admin role. (#2878, #2895)
• Automatic session token refresh: Terminus now automatically refreshes session tokens that expire during long-running command execution, preventing commands from failing partway through. (#2900)
• Fixed env:code-log crash on eVCS sites: Guarded against null commit labels that previously caused a crash. (#2911)
• Fixed plugin installs blocked by composer audit: composer audit.block-insecure is now written directly to composer.json, so plugin installs no longer fail when a pinned dependency has an open security advisory. (#2891)

How to upgrade to Terminus 4.3.3

If you use Homebrew (macOS-only) to manage your Terminus installation, you should upgrade using:

If you installed Terminus directly from the .phar file, you should upgrade using the self:update command:

For more information about this release, visit the GitHub release page.

If you have questions or concerns around Terminus, please use the Terminus issue queue.

Pantheon's external repository integration now supports GitLab in addition to GitHub. You can connect a GitLab repository to a Pantheon site via Terminus using --vcs-provider=gitlab, with support for both GitLab.com and self-hosted GitLab instances.

What's new

• GitLab repository support — Create Pantheon sites connected to GitLab repositories using terminus site:create --vcs-provider=gitlab
• Self-hosted GitLab — Connect sites to self-hosted GitLab instances using the --vcs-host=<your-gitlab-domain> flag
• Token-based authentication — GitLab uses legacy personal access tokens or group access tokens rather than OAuth. Tokens require api and write_repository scopes. Group access tokens also require a Maintainer role or higher to create repositories and manage webhooks.

For full setup instructions, see the external repositories documentation.

Terminus 4.3.2 is now available. This release adds GitLab support for VCS commands, a new --custom-domains flag for drush:aliases, and custom build path support.

Key improvements in this release

• GitLab support for VCS commands: vcs:connection:add and site:create now support GitLab as a VCS provider, enabling customers using GitLab to manage repository connections via Terminus. (#2873)
• --custom-domains flag for drush:aliases: A new flag allows including custom domains in generated Drush alias files. (#2779)
• Custom build path support: You can now pass a custom build path when creating sites. (#2851)

How to upgrade to Terminus 4.3.2

If you use Homebrew (macOS-only) to manage your Terminus installation, you should upgrade using:

If you installed Terminus directly from the .phar file, you should upgrade using the self:update command:

For more information about this release, visit the GitHub release page.

If you have questions or concerns around Terminus, please use the Terminus issue queue.