CLI-1308: Make acli push:artifact independent of a cloud account

[ayalon]

I'm coming from BLT (https://github.com/acquia/blt/issues/4736) which is sunsetting.

I used BLT in a lot of different projects, and not all of them are hosted on Acquia Cloud.

The most important command I was using is the generation of the artifact and pushing it to a git repo which could be replaced with the following command as @danepowell suggested in the thread above.

acli push:artifact (https://docs.acquia.com/acquia-cloud-platform/add-ons/acquia-cli/commands/push:artifact)

I have tried it this with a custom git repo, but unfortunately it does not work if I'm not linked with an Acquia Cloud account.

The command acli push:artifact does not need an account at all, I have patched the phar file like this: src/command/Push/PushArtifactCommand.php

    $destinationGitUrls = [];
    $destinationGitRef = '';
    if (!$input->getOption('no-clone')) {
      //$applicationUuid = $this->determineCloudApplication();
      $applicationUuid = '12345-abcd1234-1111-2222-3333-0e02b2c3d470';

The issue is, that there is no way to provide an applicationUuid without some code that validates it against the Cloud provider.

My wish into the night is straight forward:

1. It would be awesome for all BLT users, if you could add an option, that skips all the cloud checks in determineCloudApplication and just let me build and push the artifact to an arbitrary git repo as it was in BLT. This would be just a small change but very helpful.

2. To replicate the BLT behavior, it would be nice to have the post-deploy-build hook possibility. This allowed me to change the build files before it they were committed. I did not find a similar behavior.

[danepowell]

To be clear, Acquia CLI is only intended to be used by Acquia customers. I understand BLT was more general-purpose and I appreciate that leaves folks like you in a tight spot.

I've never considered the possibility of making push:artifact hosting-agnostic, but if it's as trivial as you say, I'd certainly consider it.

Any interest in opening a PR?

[ayalon]

Thanks for your honest feedback. If you consider it, I will provide a pull request.

[danepowell]

Sure, like I said, if it's only a few lines of code and doesn't disrupt the rest of the command I'll happily consider a PR.

[ayalon]

I have started creating a PR to see how much changes are involved to do it properly. In the end it was only a few. But then I rethink what happend to BLT. I didn't want to do the same mistake with a vendor lock-on on a tool, that we basically do not need. Therefore, I changed my mind and created a standalone Drush command to replace the artifact deployment. It solely depends on drush and most of the code is taken from BLT oder Acquia CLI. I think this is a more sustainable way to go. https://www.drupal.org/project/artifact_deployment

[danepowell]

That's awesome! I agree this makes sense as a Drush command. I'll try to find some time to evaluate artifact_deployment as a potential replacement for BLT deploys and/or ACLI push:artifact.

[skyred]

Acquia has a documentation which explains what blt artifact:build does https://docs.acquia.com/acquia-cms/add-ons/blt/tech-architect/deploy#section-first-time-setup. If I understand it correctly, after BLT is discounted at the end of this year, we can instead perform the manual steps below to build and deploy to Acquia Cloud:

1. composer install
2. git checkout -b THE_NAME_OF_THE_CURRENT_BRANCH-build
3. git add -f ./vendor
4. git commit -m "build artifact of THE_NAME_OF_THE_CURRENT_BRANCH"
5. git push ACQUIA_REMOTE_NAME

Step 2 is to force adding vendor directory to Git repo as part of the artifact.