[josephpage]

Context

The help of the --addon flag only documents an ID, but the flag accepts an addon type as well. Verified with the installed CLI (1.49.0):

$ scalingo backups-create -h
OPTIONS:
   --app string, -a string  Name of the current app (default: "<name>")
   --addon string           ID of the current addon (default: "<addon_id>")
   ...
   Example
     $ scalingo --app my-app --addon addon_uuid backups-create

But in practice:

$ scalingo --app my-app --addon postgresql backups
! Unable to get the addon UUID based on its type: list the addons to get the type UUID: ...

$ scalingo --app my-app --addon ad-00000000-0000-0000-0000-000000000000 backups
! The application was not found on the region osc-fr1.

With a value starting with ad-, addonUUIDFromFlags uses it as-is, otherwise utils.GetAddonUUIDFromType resolves it from the addon provider name (postgresql, redis, ... and a few aliases), and fails with no 'X' addon exists when nothing matches. So a type is accepted (a custom addon name is not), which the help does not say.

While I was in the same file: --database (preview feature) has the same kind of mismatch, its help says "ID of the current database" while the code handles a name (ExtractDatabaseNameFromCommandLineOrEnv, AddonsList(dbName), and the errors of currentDatabaseNameAndUUID mention "the given name"). Happy to drop this one if you prefer to keep the PR focused.

Changes

• fix(flags): describe the accepted values of --addon and --database
• fix(pitr): use a valid --addon value in the examples — --addon my-addon cannot work, the flag does not accept the name of an addon.

• Add a changelog entry in the section "To Be Released" of CHANGELOG.md

Notes

• only string literals are changed (no API change): gofmt -l reports nothing on the modified files.
• the --addon examples of the repository use several placeholders (addon_uuid, addon-uuid, ad-9be0fc04-...): I left them untouched, but I can normalize them in a follow-up if you want.

[EtienneM]

Thanks a lot for this contribution