Closed rfay closed 2 years ago
Sure, let me know how I can help!
@lolautruche this currently does a lot of things against your bigfoot-symfony, example: https://gist.github.com/rfay/35394655f57b5599fa1c1923887859f4
There are lots of things to be learned in trying out these hooks (now including build hooks):
Overall, these don't make me optimistic of being able to cover all (or many perhaps) of the cases of importing hooks from Platform. There are just too many assumptions built into scripts that are written for Platform.
Anyway, let's talk through this and the failures and try it out.
You can experiment with this using ddev get https://github.com/rfay/ddev-platformsh/tarball/20220630_populate_env
(You'll need to remove the opcache setting in your custom php to get ddev to come up)
Thanks @rfay !
.global/bin
is expected to be in $PATH
. Sorry about that, I forgot to tell you. About /tmp/prod
, I'm not sure to get what you're talking about.I'm still pretty sure we can cover most (if not all) of the cases with hooks đ
Oh, I note
pkill -f php-fpm
, which brings down the container, as this is unexpected. There are a lot better ways to do a reload (pkill -USR2 for example)bash: line 26: warning: here-document at line 18 delimited by end-of-file (wanted
EOS')`If you'll link me to these I'll do a PR. @fapot would love to have your input on those issues.
It seems that we're missing an environment file which is expected to be sourced (/app/.global/environment
).
It contains the following:
export MIX_HOME="$PLATFORM_APP_DIR/.global/mix"
export COMPOSER_HOME="$PLATFORM_APP_DIR/.global"
export NPM_CONFIG_PREFIX="$PLATFORM_APP_DIR/.global"
export PATH="$PLATFORM_APP_DIR/.global/bin:$PLATFORM_APP_DIR/.global/composer/composer/vendor/bin:$PLATFORM_APP_DIR/.global/vendor/bin:$PATH"
export GEM_PATH="$PLATFORM_APP_DIR/.global:$PLATFORM_APP_DIR:/usr/share/rubygems-integration/all"
export PYTHONUSERBASE="$PLATFORM_APP_DIR/.global"
That will be huge, thanks. Who expected that to be sourced? Platform? It's easy to do, looks like it will solve all kinds of problems, especially the PATH problem, which was kind of ugly.
Also, containers may have /app/.environment
files, which are supposed to be sourced whenever present.
It's supposed to contain shell, like a .bashrc
The EOS error is from https://get.symfony.com/cloud/configurator - there is no EOS. @fabpot I'll do a PR if I know where that is on github. It's a bug that should be fixed.
I sent an email to Fabien about the cloud configurator, copied you @lolautruche
@fabpot kindly fixed the two outstanding items with cloud configurator - not killing off php-fpm and instead reloading and the missing EOS.
There are a couple of other items now that I emailed him about,
1. Could you please change line 46 of .global/bin/symfony-build
export NVM_DIR=${APP_DIR}/.nvm
to be
export NVM_DIR=${NVM_DIR:-${APP_DIR}/.nvm}
so it doesn't overwrite NVM_DIR if it's already set?
DDEV already has NVM support and nvm is set up.
2. It seems the cloud configurator installs the platform cli unconditionally - shouldn't it check to see if it's already installed first? (line 16) Maybe instead of
(curl -fsS https://platform.sh/cli/installer | php -n -d"$(php -n -r 'extension_loaded("json")||print("extension");')"=json.so -d extension=phar.so -d extension=mbstring.so -d extension=posix.so -d extension=curl.so) || true
if [ ! command -v platform >/dev/null ] ; then
(curl -fsS https://platform.sh/cli/installer | php -n -d"$(php -n -r 'extension_loaded("json")||print("extension");')"=json.so -d extension=phar.so -d extension=mbstring.so -d extension=posix.so -d extension=curl.so) || true
fi
Again, if there's a way I can fix this with a PR I'll happily do it.
@lolautruche the default drupal template hooks have drush -y config-import
without specifying the source of the config, so it always fails with " This import is empty and if applied would delete all of your configuration, so has been rejected."
This command results in the same output if executed in the Platform.sh site.
Shouldn't this be specifying a config for import? Or something?
Some of the handling of environment is starting to mature, and I've moved it to a homedir setup, but there are still things that don't work across all the projects I'm working with (and my platform token doesn't even get your project any more for no reason I understand)
Can we spend an hour or two debugging through environment variables in different contexts?
Shouldn't this be specifying a config for import? Or something?
If this also happens on Platform, it means that we probably have a bug in our template (ping @chadwcarlson @gilzow @thomasdiluccio). You can find the template source here: https://github.com/platformsh/template-builder/tree/master/templates/drupal9/files
Can we spend an hour or two debugging through environment variables in different contexts?
Sure, let's do this today during our call, together with @gilzow đ
Thanks - @fabpot fixed the things I emailed about as well. See you today!
PLATFORM_PROJECT_ENTROPY
may not work with logins or other things that use salt, unless âŠPaul on routes: this is a really good source of info on the routes. Under âResponsesâ, expand âdefaultâ to go get a list of properties and their definitions
(from discussion in https://platformsh.slack.com/archives/C0JE8AE13/p1657613433824679 )
Paul and Jerome will figure out how to find out environment id
If you haven't already given it an ID via
-e
or --environment
option<environment>
first argument of some commands (like platform env:del main
)-p
PLATFORM_BRANCH
environment variableThen, it will look for the "current environment" via
And if no environment is found then it'll ask you to choose one.
Also, many commands also need the app or worker name too, if there is more than one (similar process: from the --worker
option, --app
option, PLATFORM_APPLICATION_NAME
variable, or asking).
More details on how this done in the CLI's Selector
class.
@lolautruche re: https://github.com/platformsh/ddev-platformsh/pull/17#issuecomment-1181473636 - it seems to me like there isn't a reliable way to determine PLATFORM_ENVIRONMENT given only token+code, same with PLATFORM_PROJECT, so I'll just have to ask for both. Already doing that in latest commit, but there's a problem with merging config.*.yaml with config.yaml, already knew it would rear its head. Hope to solve in
Most of the things addressed in this PR are now working, even though some of them are shortsighted and will have to be revisited, especially the location of the environment variables PLATFORM_ENVIRONMENT and PLATFORM_PROJECT. We're having to ask for token and both of those, but we should be storing it in the config.platformsh.yaml
, which we can't do until ddev does config file merging instead of override, which has an open approved PR, https://github.com/drud/ddev/pull/3983
If anybody would like to try this out, it would be great. ddev get https://github.com/rfay/ddev-platformsh/tarball/20220630_populate_env
BTW, ddev platform
is working nicely, so you can ddev platform ssh
for example.
PLATFORM_PROJECT
can be retrieved using the following command:
platform project:info id
Thanks @lolautruche - that's outstanding, but how in the world can it figure that out without $PLATFORM_PROJECT already being set? Especially with a github project?
$ platform project:info id
Enter a number to choose a project:
[0] BigFoot Symfony EU-3 (6j4ypl5iendqc)
[1] d9mariadb (nf35mudfn23bi)
[2] d9mysql (u2gvy3z2olb5s)
[3] d9postgres (cojj67jzpv5vk)
[4] ddev (drume6uf7v66e)
>
rfay@bf2-web:/var/www/html$ export PLATFORM_PROJECT=6j4ypl5iendqc
rfay@bf2-web:/var/www/html$ platform project:info id
6j4ypl5iendqc
Holly Molly đ± ! I think you have an issue within the container, same issue than for the current environment AFAICT, but I don't know why. I don't have this issue myself (within or outside the container).
Maybe @pjcdawkins can help
I'm pretty sure we decided in slack conversation that there's no way to be assured of knowing the project unless you already know the project. If you look around, it's not in the .platform*. If it's a direct platform-git checkout, then platform cli can look at the git remote and perhaps guess the project from that, but not for a github project like yours.
Yes indeed, if it's fresh and not linked (using platform project:set-remote
), we won't be able to guess it.
So my suggestion is to:
platform projects --count 0
platform set-remote <project_id>
Nitpicking that - it's platform project:set-remote
, and it asks for the ID itself if you don't provide one (although it's an autocomplete, not a list)
I was waiting for https://github.com/drud/ddev/pull/3983 to land to continue here, and it took more work by far than I anticipated, even with a community member starting it off and doing pretty well. But I ended up running with it, then discovering flaws, etc.
Then I returned here and have decided that the approach in this PR is already about as good as it's going to get. It captures the Platform.sh info and puts it in config.yaml (using ddev config
). I was hoping it could go into our config.platformsh.yaml
instead, but we're replacing that at the time we're asking for it, so it makes a bit of a mess, and having it in the project config.yaml is not necessarily that bad.
So I'm going to pull this and move on to mounts, which should be interesting and less exotic.
First work on trying to populate environment variables, including PLATFORM_ROUTES
Unfortunately, I'm probably stuck. Will need to do a collaborative debugging session to understand this I think.