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.
- config_test.go: create app dir at DOKKU_ROOT for VerifyAppName and
ensure global config parent directory exists
- migrateGlobalEnv: set dokku:dokku ownership on global ENV file after
writing so deploy processes running as dokku can read it
The post-create trigger only created the property directory at
DOKKU_LIB_ROOT/config/config/{app}/, but getAppFile() writes the
ENV file to DOKKU_LIB_ROOT/config/{app}/ENV. Add setupAppConfigDir
to create and permission the ENV directory in both post-create and
install triggers, and clean it up on post-delete.
- Move migrateGlobalEnv() before UnfilteredDokkuApps() so the global
config directory is created even on fresh installs with no apps
- Add DOKKU_LIB_ROOT to Go test env vars in tests.mk
- Use DOKKU_LIB_ROOT instead of DOKKU_ROOT in getGlobalFile() to match
the intended new config path layout
- Add missing comma in filepath.Join for old app ENV migration path
- Revert common_test.go app dirs to DOKKU_ROOT since app detection
still uses AppRoot()
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 :)
