post-code-deploy should not run on ACSF

[danepowell]

My system information:

• BLT version: 9.0.5

Currently, it seems like best practice for ACSF customers is to set up both Cloud Hooks and ACSF Factory Hooks (recipes:acsf:init:hooks and recipes:cloud-hooks:init).

The problem is that the post-code-deploy hook doesn't really make sense on ACSF, because we already have the db-update factory hook that should take effect whenever someone explicitly deploys new code via the ACSF UI.

It can cause problems because it runs whenever you stage environments, when you probably don't want hooks to be running.

On the other hand, post-code-update still makes sense to keep because I don't think there's any other way to automatically run updates when you push new code without explicitly starting a deploy via the ACSF UI.

[grasmash]

Currently, it seems like best practice for ACSF customers is to set up both Cloud Hooks and ACSF Factory Hooks (recipes:acsf:init:hooks and recipes:cloud-hooks:init).

I was under the impression that ACSF customers should use only factory hooks.

What is the BLT requirement for this issue? This seems like it's a question about ACSF best practices and features.

[danepowell]

Factory hooks alone are not sufficient. For instance, if you have a branch deployed and push a new commit to that branch, no factory hooks are executed that I'm aware of. Only the post-code-update cloud hook gets run.

It sounds like we need to clearly define, document, and possibly modify the interaction between recipes:cloud-hooks:init and recipes:acsf:init:hooks.

I would suggest:

1. Make recipes:cloud-hooks:init a dependency of recipes:acsf:init:hooks, so that Cloud Hooks are sure to get created when ACSF is initialized for a project.
2. Add a check to BLT's implementation of the post-code-deploy hook to gracefully exit if it detects that it's running on ACSF.

[malikkotob]

From Acquia Docs:

Acquia Cloud Site Factory hooks differ from Acquia Cloud hooks. Because Acquia Cloud hooks are not designed for use with multisites, even though Acquia Cloud hooks exist in Acquia Cloud Site Factory, their use in Acquia Cloud Site Factory is unsupported.

@danepowell does the above note change anything in your comment? If not, should we work the docs team to indicate that cloud hooks are something that should be supported, or is that a separate discussion?

[danepowell]

I'm aware that Cloud Hooks are not officially supported on ACSF, but unfortunately they are the only solution to this particular use case of running updates when pushing a new commit to a deployed branch. I'll submit a feature request to ACSF.

So my suggestion stands, until that feature is added to ACSF or unless you know of a better alternative.

[lcatlett]

Cloud Hooks are disabled in BLT on ACSF post-code-deploy already under the assumption that a tag is deployed in production since this would execute deploy:update in the ACSF update environment during an ACSF code update. Running Cloud Hooks via post-code-update executes on each commit to a branch on ACE / ACSF so using them is more suited for a development or integration environment. ACSF does not currently have equivalent Factory Hooks so using post-code-update for this purpose is not supported, however the overhead of running updates in an alternative way may warrant accepting the risks of using an unsupported strategy for this purpose. Since this is not an Acquia supported feature, we have decided to add a validate task to BLT that will fail builds using unsupported Cloud Hooks on ACSF builds. This test can be optionally disabled and will include help text detailing the implied risk of doing so.

Currently it is assumed that ACSF projects are not running recipes:cloud-hooks:init since it is not supported so the check that was included in e339a75#diff-609d44cc2cef3d8037c9900e8d828d9d can be re-added as an additional check.

[danepowell]

I'm pretty sure in my test the other day post-code-deploy was not disabled on ACSF (the BLT implementation tried to fire and caused a problem), that's why I opened this issue.

[malikkotob]

Interesting, it looks like it's disabled for ACSF in 8.9.x, but not 9.x as part of the work @lcatlett got going here, ultimately replaced by #2685. Should we just do the same in 9.x?

[danepowell]

Makes sense to me!

[jhedstrom]

Sorry to ping this old issue, but there's very little documentation around best practices for deploying a branch to a lower environment (eg, dev), for testing of the latest code.

On the other hand, post-code-update still makes sense to keep because I don't think there's any other way to automatically run updates when you push new code without explicitly starting a deploy via the ACSF UI.

Without a post code deploy hook available, what is the recommended best-practice for continuous deployment to a lower environment? We have acquipa pipelines automatically building and committing the artifact, we just can't seem to find a documented way to trigger updates and config imports.

[jhedstrom]

Updating this in case others encounter it.

The solution we came up with for the above, to continuously deploy to the ACSF dev environment was to create a bash script, and called that from the Acquia pipeline. The script itself had to handle checking for the environment, and would exit if it wasn't dev:

# Only run this on the dev site
# Change `develop` bit to whatever the mainline branch one is continuously deploying to `dev`.
if [ ! "${DEPLOY_VCS_PATH}" = "pipelines-build-develop" ]; then
  exit
fi

# Wait 60 seconds to make sure the code gets deployed (previous step).
sleep 60

# Loop through hard-coded site aliases here and call `vendor/bin/drush @foo.dev updb`, etc here.