Clarification on cht --url=https://<username>:<password>@172-20-252-111.local-ip.medicmobile.org:10443/ -- Command and Its Impact

Hello CHT community,

I recently ran the following command from my local cht-project directory:

cht --url=https://<username>:<password>@172-20-252-111.local-ip.medicmobile.org:10443/ --

I didn’t specify any additional arguments or subcommands, just the --url.
To my surprise, this triggered a full deployment pipeline to the live CHT instance and started executing the following actions::

INFO Actions:
     - check-git
     - compile-app-settings
     - backup-app-settings
     - upload-app-settings
     - convert-app-forms
     - convert-collect-forms
     - convert-contact-forms
     - convert-training-forms
     - validate-app-forms
     - validate-collect-forms
     - validate-contact-forms
     - validate-training-forms
     - backup-all-forms
     - delete-all-forms
     - upload-app-forms
     - upload-collect-forms
     - upload-contact-forms
     - upload-training-forms
     - upload-resources
---
     - upload-branding
     - upload-partners
     - upload-custom-translations
     - upload-privacy-policies
     - upload-extension-libs
     - upload-database-indexes

It actually connected to the live instance, and executed all the commands check-git to upload-resources, and uploaded my local versions.
However, it stopped at the upload-resources step when CHT detected that the server’s config had been modified since my last upload. It then prompted me to choose:

  1. Overwrite the changes – Push my local resources and replace server ones.
  2. Abort – Cancel so I can pull the latest from the server first.
  3. View diff – See what’s different before deciding.

My questions:

  1. Is cht --url=... without a subcommand intentionally designed to run a full deployment?
  2. Is there a built-in safe or dry-run mechanism to connect and validate without pushing changes (especially to production)?

Any guidance would be appreciated, especially to avoid accidental production deployments in the future.

Thanks,

Yes. This is the way to specifically trigger the “build/deploy all” (instead of having to explicitly call out each individual action). Perhaps the docs should be more explicit about this… :thinking:

If you just want to see the available actions, but not actually do anything, you can include the –help flag.

All of the actions that can actually work without connecting to a CHT instance can be run without providing a –url parameter. For example, you can run cht convert-app-forms validate-app-forms and it will build/validate your app forms locally without making any connecting to a CHT instance. The same goes for cht compile-app-settings which will compile your local settings config (tasks, contact-summary, etc) without uploading it anywhere. (Note that even if you provide the –url parameter with these commands, nothing will be uploaded to the server.)

In summary, it should be very clear from the action name/description that it is going to make a state-full change on the server (e.g. any of the upload-* commands). The rest should have no impact on the server, but instead operate on the config locally. If you want to be doubly sure that nothing is getting pushed to the server, simply avoid including the –url parameter. Unfortunately, we do not currently have any meta-action for running all the offline-only actions, so you have to specify each action explicitly.

2 Likes

@Kenyuri - following up to say I’ve opened a PR to improve the help text of the cht command.

The current proposed warning in the PR is:

Note: If <actions>,<options> or <params> are notpassed but one of --local or --instance or --urlispassed,all supported actions are called.

If you have any ideas on the wording, head over to the PR - your input is welcome!

1 Like