Install steps run in alphabetical order of the enabled plugin directory, so `apps`, `builder`, and `checks` read an app's environment before the `config` plugin had moved the `ENV` file to its new location. The read came back empty, so their deprecated `DOKKU_*` variables were never migrated to the matching plugin property and were never unset, with nothing reported either way: `dokku config:show` kept listing the variable while the plugin behaved as though it were unset. The relocation now runs before any deprecated variable is read, whatever the install order, and each old file is removed as soon as it has been drained rather than on a later install, which also covers the global file that was never removed at all. A file that reappears at the old path can only have been written by hand, so it is merged in with a warning naming its keys instead of being discarded.
This is almost certainly the correct default for Dokku. While it's a BC break and might cause an increase in memory usage, the api is mostly internal and therefore this is safe to use.
This better follows Heroku's output and is more useful to users. The subcommands will be treated as the primary, documented versions, while the aliases are there for convenience.
Closes#5362
The trigger in use _should_ be config-get-global, but some calling code does not check, so adding support here will ensure the calling code gets what it expects.
Refs #5269
This MR splits out the logic such that there is now a binary that handles function based calls without validating the app name. We should only every check the app name for the subcommands and not internally. Internal calls should have their arguments taken at face value.
This will allow dropping many of the "source config/functions" calls littered over the codebase. Plugin triggers are the way to perform cross-plugin communication :)
When setting the `--app` flag, there was a special case for the config plugin. This plugin used to take the `--no-restart` flag as the first argument - and still did until this change - resulting in an invalid call to the plugin subcommands. What is worse is that this functionality carried over to all other plugins as they were rewritten in golang, and thus the issue spread without us knowing.
The fix is to support GNU flag parsing rules, which Golang does not do by default (Because Of Reasons™). Switching to `github.com/spf13/pflag` fixes this issue, and also allows positional arguments to be placed wherever, even in the middle of flags.
Closes#4255
This hopefully makes it a little easier to work with as the tooling is now based on something in golang core.
- move columnize usage to common plugin
- remove old vendor files
This change refactors the compiled golang plugins into 3 distinct binaries:
- commands: already existing
- subcommands/subcommands: entrypoint into all subcommands
- triggers: entrypoint into all triggers
It then further symlinks triggers and subcommands to the built binaries. This results in both a much faster build process as well as smaller package size.
This change adds json output as both key/value as well as a list of objects. The former can be used in quick scripting environments, while the latter allows higher-level languages to have a bit more structure around how environment variables are declared. Specifically, systems such as kubernetes understand the latter method, while the former can be used within Nomad job files.
