This repository has been archived by the owner on Jan 30, 2024. It is now read-only.
Use Capistrano's HOSTFILTER feature instead of rolling our own. #10146
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It turns out that Capistrano 2's
HOSTFILTER
feature does exactly what we've been trying to implement ourselves in ourTARGET_MACHINES
change. Specifically, it deploy to just the machines specified inHOSTFILTER
and ignores any tasks for roles which the machine doesn't have.The motivation for this is to fix deployments of Whitehall to single nodes, which happens when an EC2 instance goes away and when we scale up. This has been broken since Sep 2019 (alphagov/govuk-app-deployment#325). My previous attempt, alphagov/govuk-app-deployment#358, didn't solve the problem because Cap fails when a task has no applicable machines (for example
restart_backend
has no applicable machines when deploying to awhitehall_frontend
machine).There is a caveat to this, which is that
HOSTFILTER
appears to have been removed in Capistrano 3 and replaced with a similarHOSTS
feature, which sadly doesn't do what we need; it tries to run all tasks on the specified hosts regardless of whether the tasks apply to the role or not.So if for any reason we want to upgrade to Capistrano 3, we'd need to find an alternative solution. I don't imagine that's very likely though, given that we've been on Cap 2 for so many years.
Tested in Integration by making the same change manually on the Jenkins job temporarily.