ddev / ddev-platformsh Goto Github PK

DDEV doesn't need to manage settings for Platform.sh add-on projects.

• #17 did build hooks and deploy hooks, but post-deploy hooks are not yet handled. Will need a test environment for them.

In Platform.sh container, the "app dir" is /app. As such, one expect the same in a local container.
/app might be a symlink to /var/www/html.

The doc root (or web root) is always relative to this app dir and is defined in .platform.app.yaml (more details from the YAML reference)

Testing out blog.blackfire.io I see that config.platformsh.yaml ends up with

database:
  type: mysql
  version: 10.2

which is obviously impossible, so the mapping here isn't being done right.
.platform.app.yaml has

relationships:
    database: "mysqldb:mysql"
    cache: "memcached:memcached"

and services.yaml has

mysqldb:
    type: mysql:10.2
    disk: 2048

That should work. In relationships lines, the left part of the pair (mysqldb) in this case is free form and should be joined to the item of the same name in services.yaml

While the DB container worked out of the box, the redis container was missing. I got it running quickly with ddev get drud/ddev-redis. The PLATFORM_RELATIONSHIPS variable was missing the configuration for the redis service defined in services.yaml, so I had to create a fallback. Would be great if this works out of the box.

.platform.app.yaml

relationships:
  database: "mysql:mysql"
  rediscache: "cacheredis:redis"

services.yaml

mysql:
  type: mysql:10.5
  disk: 4096
cacheredis:
  type: redis:6.2

redis config

$platformRelationships = json_decode(base64_decode(getenv('PLATFORM_RELATIONSHIPS')));

return [
    'redis'   => [
        'host' => $platformRelationships['rediscache'][0]['host'] ?? 'redis', // Fallback for DDEV
        'port' => $platformRelationships['rediscache'][0]['port'] ?? 6379, // Fallback for DDEV
    ],
]

Read basic settings from.platform.app.yaml and reflect them into config.platformsh.yaml

• Project name
• PHP version from type
• PHP extensions from runtime
• Env variables (basic ones including basic $PLATFORM_ ones))
• Mount Names

Either on post-start or when running ddev get

ddev exec platform self:update --no-major --yes

Over in

• ddev/ddev#4409

@flovntp pointed out a situation where the symfony-build fails, but the hooks continue on.

I think it would be reasonable to turn on fail_on_hook_fail: true for this integration, so later things don't show up from earlier failures.

I know there are a couple of places where the fails are inconsequential, but this is a situation where things should definitely stop and the failure should be pointed out where it actually is.

We can now explore all the mounts, instead of using drupal-centric existing situation, so the ddev pull platform should by default pull down all the "mounts".

Scenario:

Project is cloned locally using platform get <projectid>. Project is configured to use type: "php:7.4" in .platform.app.yaml. DDEV+ddev-platformsh is used to develop locally. Upstream changes occur, changing the type to php:8.1 with composer updates and other changes. git fetch & git pull are used to update the local copy of the repository. DDEV is restarted.

Expected outcome: web application container is update to reflect the updated type (php 8.2) in the application.

Actual outcome: web application container remains the same as initially configured (i.e. php 7.4)

Ideally, there would be a warning that the current platform configuration files are different from the ddev configurations and that a rebuild (possibly a ddev rebuild command?) needs to occur.

Only way I know to "fix" the application container currently is to either rerun the ddev get platformsh/ddev-platformsh command and walk through all the steps, or manually update the the .ddev/config.platformsh.yaml and then do a ddev restart.

When drupal8 and drupal9 templates get to

php ./drush/platformsh_generate_drush_yml.php
they fail on ddev start with

$ php drush/platformsh_generate_drush_yml.php
Failed to find a site URL

Note that since DDEV doesn't need a drush.yml this may not be that relevant, but it would be better if it worked.

Unless there's some fancy way of making ddev platform login work, I'd say the best way is using a token:

https://docs.platform.sh/administration/cli/api-tokens.html

There are different ways of doing it, env var right now seems to work just fine:

You can have a config.platformsh.yaml file that you won't commit with:

web_environment:
  - PLATFORMSH_CLI_TOKEN=<YOUR_TOKEN>

Sorry I am not getting right into a PR, can't right now, but thought of at least sharing this.

As with any database server, changing the server while keeping the same data may often not work out. For example, if you have a working database on MariaDB 10.3, and you change the server type to MySQL 8.0, it will choke on the way up. And DDEV currently has no easy way to know the type of the existing data, in /var/lib/mysql even though the type is in there in a file that DDEV adds, but it can't be seen without starting a container with that volume mounted.

People stumble on this regularly and the docs cover it, and it makes sense.

But it would be a much better user experience if we could:

• Detect the version of the database in the volume mount.
• Detect if there is actually data there
• If a downgrade or a type change, warn people or... if the 'db' database is actually empty, rebuild the whole thing silently.

Discussion in https://platformsh.slack.com/archives/C03GRG19L2E/p1654616860043129

This issue should probably be moved to drud/ddev, but dropping it here because it has significant impact on this project, where most people will probably have an existing mariadb:10.3 database (but possibly empty) before pulling this add-on, making it hard to give them the type they have in the upstream hosting (if it's different).

Upon installation you are requested to provide the project id:

Please enter your platform.sh project ID (like '6k4ypl5iendqd'):

Ideally the ID should be acquired from the existing platform config rather than asking the user to provide it.

It is my understand that the platform project id is available under .platform/local/project.yaml, right?
(I've only been to projects that were already configured with platform, so I might lack some knowledge here)

I'd love to hear other peoples thoughts on that though

Related: #7

Figlet is expected to be in the web container, http://www.figlet.org/

The current scripts that generate the JSON content for $PLATFORM_RELATIONSHIPS currently has an arbitrary fixed key (e.g., database for DB, essearch for Elastic Search, etc.

The value for this key must actually match the name of the relationship that is defined in .platform.app.yaml (example in Bigfoot app):

# .platform.app.yaml

# The relationships of the application with services or other applications.
# The left-hand side is the name of the relationship as it will be exposed
# to the application in the PLATFORM_RELATIONSHIPS variable. The right-hand
# side is in the form `<service name>:<endpoint name>`.
relationships:
    database: "mysqldb:mysql"
    cache: "memcached:memcached"

In the example above, the value to take into account is the relationship key (database, cache).

Install global PHP dependencies in the container, as configured in .platform.app.yaml

I think this naming may be shortsighted, as it assumes that there would only be one "platform" add-on. No big deal, just thinking about it. May be better to name it based on its function in the end.

But we can talk about that when we get a little farther down the line. Doesn't really matter until we start labeling it and it's visible to people.

List of php-based templates that in some way use/depend on PLATFORM_ROUTES

• wordpress-bedrock
• wordpress-vanilla
• wordpress-woocommerce
• drupal8-multisite (both directly and via psh config reader - 1, 2)
• drupal9-multisite (both directly and via psh config reader - 1, 2)
• magento2ce
• nextcloud
• laravel (via laravel-bridge, via psh config reader)
• typo3 (via psh config reader)
• wordpress-composer (via psh config reader)
• drupa8-govcms8 (via psh config reader - 1, 2)
• drupa9-govcms9 (via psh config reader)
• drupal8-opigno (via psh config reader)
• drupal8 (via psh config reader)
• drupal9 (via psh config reader)
• pimcore (via psh config reader)

I've come across a couple of projects that rely on the PLATFORM_CACHE_DIR environmental variable and fail to install correctly when using DDEV with this add-on.

Would it be possible to add this env var to the default mappings? For now I'm manually adding it into ./.ddev/config.platforsh.yaml and restarting, but having it by default would be appreciated. Thanks!

Feature request:
With the ddev pull platform command prompt the user for the environment they wish to pull from, defaulting to the current checked out branch.

Reasoning:
Often when working with colleagues, we need to debug/troubleshoot a feature we're developing in a non-production branch. This often involves needing to sync that environment's database into the local development environment to further work on. The current implementation of ddev pull platform limits the user to the environment they choose during the initial ddev get platformsh/ddev-platformsh or manually updating the .ddev/config.yaml file.

Ideally, when initiating the ddev pull platform command, the user would be given a choice of currently active platform.sh environments, with the default selection matching the current locally checked out environment. This would allow for users to quickly and easily replicate platform.sh environments locally without having to manually update files.

"Official" ddev add-ons are in github.com/drud, and are maintained and tested.

But since this add-on is maintained and tested and has a bright future... can it be an "official" add-on?

Is there a way DDEV can define "offical" that is not "in the drud org"?

We have decided that python: dependencies will not be supported (python2)

Other keys should also be enforced.

Shortcut for ddev exec platform

Just tried to upgrade from 0.4.4 of ddev-platformsh to 0.5.0.
In an existing project that already uses ddev, already had ddev-platformsh installed (0.4.4), and where ddev was not currently running, I ran

ddev get platformsh/ddev-platformsh 

ddev downloaded the tarball for 0.5.0, and then informed me:

Using existing PLATFORMSH_CLI_TOKEN.
 
Using existing PLATFORM_PROJECT from project config.yaml.
 
Using existing PLATFORM_ENVIRONMENT from project config.yaml.

It then showed:

could not process pre-install action '#ddev-nodisplay

followed by several lines of bash code. At the end it showed

: exit status 1, output=There is an existing database in this project that doesn't match the upstream database type.
 Please use 'ddev delete' to delete the existing database and retry, or try 'ddev debug migrate-database mariadb:10.4' to migrate the database.

but i cant tell if that is still part of the bash code, or if it is an actual message. The db in the upstream is:

db:
    type: mariadb:10.4

and the db info in .ddev/config.yaml is

database:
  type: mariadb
  version: "10.4"

so there shouldn't be a mismatch.

The platform-setup app would host most of the setup commands needed for the add-on.
Usage of Go is justified by the fact of staying OS agnostic (especially working on Windows).

Examples of commands

• platform-setup init (for base interactive setup)
• platform-setup config (generate DDEV config out of Platform config

PHP extensions can be declared in the .platform.app.yaml:

runtime:
    extensions:
        - blackfire
        - http
        - igbinary
        - redis
    disabled_extensions:
        - sqlite3

This should be reflected in DDEV.

Follow up to #32. If I am not mistaken, the PLATFORMSH_CLI_TOKEN will end up in config.yaml which will likely trigger a commit with it.

On #32 you said it was a config.platform.sh being created, but you are adding a lot of useful things from .platform.app.yaml that very likely needs to be committed, so something to think about:

git add -f .ddev/config.platformsh.yaml on install? If so, PLATFORMSH_CLI_TOKEN should likely go elsewhere, config.platormsh.private.yaml?

In the generated config.platformsh.yaml file, I see the following PLATFORM_ROUTES variable

web_environment:
- "PLATFORM_ROUTES=eyAiJHtEREVWX1BSSU1BUllfVVJMfSI6IHsgInByaW1hcnkiOiB0cnVlLCAiaWQiOiBudWxsLCAicHJvZHVjdGlvbl91cmwiOiAiJHtEREVWX1BSSU1BUllfVVJMfSIsICJhdHRyaWJ1dGVzIjoge30sICJ1cHN0cmVhbSI6ICJkcnVwYWwiLCAidHlwZSI6ICJ1cHN0cmVhbSIsICJvcmlnaW5hbF91cmwiOiAiaHR0cHM6Ly97ZGVmYXVsdH0vIiB9IH0="

Decoding this, I get

echo "eyAiJHtEREVWX1BSSU1BUllfVVJMfSI6IHsgInByaW1hcnkiOiB0cnVlLCAiaWQiOiBudWxsLCAicHJvZHVjdGlvbl91cmwiOiAiJHtEREVWX1BSSU1BUllfVVJMfSIsICJhdHRyaWJ1dGVzIjoge30sICJ1cHN0cmVhbSI6ICJkcnVwYWwiLCAidHlwZSI6ICJ1cHN0cmVhbSIsICJvcmlnaW5hbF91cmwiOiAiaHR0cHM6Ly97ZGVmYXVsdH0vIiB9IH0=" | base64 --decode | jq
{
  "${DDEV_PRIMARY_URL}": {
    "primary": true,
    "id": null,
    "production_url": "${DDEV_PRIMARY_URL}",
    "attributes": {},
    "upstream": "drupal",
    "type": "upstream",
    "original_url": "https://{default}/"
  }
}

However, this doesn't match my routes.yaml, which is:

https://{default}/:
  id: secure
  cache:
    enabled: true
    default_ttl: 0
    cookies: [ '*' ]
    headers: [ 'Accept', 'Accept-Language' ]
  redirects:
    expires: -1s
    paths: {}
  ssi:
    enabled: false
  type: upstream
  upstream: surveylab:php
  tls:
    strict_transport_security:
      enabled: true
      include_subdomains: true
      preload: true

The correct encoding of this routes yaml is as follows:

echo "eyJodHRwczovL3NkYmItaGl0LmxuZG8uc2l0ZS8iOnsicHJpbWFyeSI6dHJ1ZSwiYXR0cmlidXRlcyI6e30sImlkIjoic2VjdXJlIiwib3JpZ2luYWxfdXJsIjoiaHR0cHM6Ly97ZGVmYXVsdH0vIiwiY2FjaGUiOnsiZW5hYmxlZCI6dHJ1ZSwiZGVmYXVsdF90dGwiOjAsImNvb2tpZXMiOlsiKiJdLCJoZWFkZXJzIjpbIkFjY2VwdCIsIkFjY2VwdC1MYW5ndWFnZSJdfSwicmVkaXJlY3RzIjp7ImV4cGlyZXMiOiItMXMiLCJwYXRocyI6e319LCJzc2kiOnsiZW5hYmxlZCI6ZmFsc2V9LCJ0eXBlIjoidXBzdHJlYW0iLCJ1cHN0cmVhbSI6InN1cnZleWxhYiIsInRscyI6eyJzdHJpY3RfdHJhbnNwb3J0X3NlY3VyaXR5Ijp7ImVuYWJsZWQiOnRydWUsImluY2x1ZGVfc3ViZG9tYWlucyI6dHJ1ZSwicHJlbG9hZCI6dHJ1ZX19fX0=" | base64 --decode | jq
{
  "https://sdbb-hit.lndo.site/": {
    "primary": true,
    "attributes": {},
    "id": "secure",
    "original_url": "https://{default}/",
    "cache": {
      "enabled": true,
      "default_ttl": 0,
      "cookies": [
        "*"
      ],
      "headers": [
        "Accept",
        "Accept-Language"
      ]
    },
    "redirects": {
      "expires": "-1s",
      "paths": {}
    },
    "ssi": {
      "enabled": false
    },
    "type": "upstream",
    "upstream": "surveylab",
    "tls": {
      "strict_transport_security": {
        "enabled": true,
        "include_subdomains": true,
        "preload": true
      }
    }
  }
}

After setting up ddev, I ran ddev drush cr and got the following error:

Trying to drush The branch variable is not defined. Are you sure you're running on Platform.sh?

If I set PLATFORM_BRANCH=my-dev-branch in config.yaml under web_environment and ddev restart, then drush works.

My install

ddev config global --mutagen-enabled

ddev config

project name: myRepo
docroot: web
type: php (a Drupal 9 site)

ddev get platformsh/ddev-platformsh

Enter the platform ID (abcdefg).
And enter the environment (my-dev-branch).

ddev composer install

After all this, config.yaml looked like this:

web_environment:
- PLATFORM_APPLICATION_NAME=drupal
- PLATFORM_ENVIRONMENT=my-dev-branch
- PLATFORM_PROJECT=abcdefg

So it seems to me that the solution is to set PLATFORM_BRANCH to the currently checked out git branch, or to ask the user to provide the branch as well (is it always the same as PLATFORM_ENVIRONMENT? it is in my case, but I don't know about others.)

In any case, it seems drush doesn't work without setting PLATFORM_ENVIRONMENT, and I couldn't find this documented anywhere, so I'm opening this issue.

I was just thinking about this on a platform project I am working on (I don't use the full addon) but I was annoying at always getting the update notification.

My not so important concern here is that the RUN command will be cached, so eventually you'll get again the same behavior as using the standard ddev image.

I thought different ways of adding it to the Dockerfile, the most obvious one being downloading a specific version phar that you'll have to update everytime there's a new version, probably too annoying.

In the end I added as a post-start hook. I know it will run every start, but I rather live with that. Just sharing this thought for you to consider.

Using a Drupal 9 multisite with two databases.
When executing the command: 'ddev pull platform' it encounters multiple relationships and stops.
It askes for a --relationship flag but the ddev command doesn't recognise it.

ddev pull platform
You're about to delete the current database and files and replace with the results of a fresh pull.
Would you like to continue? [Y/n] (yes): yes
Authenticating...
Obtaining database...
More than one relationship found.
Use the --relationship (-r) option to specify a relationship. Options:

The plugin creates post-start commands to run the platform.sh build and deploy hooks. These commands are run on every ddev start. However, I only want to run the build and deploy hooks when I first install the project, not every time I start the project.

I'm migrating from lando, where we had lando rebuild (runs the hooks) vs lando start (only starts containers). Can you point me to any resources how to achieve the same separation with DDEV?

This is the hooks section created by the plugin:

hooks:
  post-start:
    - exec: platform self:update -qy --no-major || true
    - exec: '[ ! -z "${PLATFORMSH_CLI_TOKEN:-}" ] && (platform ssh-cert:load  -y || true)'
    - composer: install
    # platformsh build hooks
    - exec: |
        bin/build-hook
    # platformsh deploy hooks
    - exec: |
        bin/deploy-hook

@lolautruche mentions that this repo would be a good one for experimentation with this add-on:
https://github.com/platformsh/wordpress-performance

• ddev debug configyaml is a better way to see what's currently configured than reading own config.yaml
• Project env vars should be added to config.platformsh.yaml instead of config.yaml now that env var merging works in DDEV.

Services are configured in .platform/services.yaml and referenced in .platform.app.yaml.
Let's reflect them in DDEV, in config.platformsh.yaml.

A lot of services are available in Platform.sh, but we want to reflect the ones that are already available out-of-the-box in DDEV.

Configuring them includes the exposure of the $PLATFORM_RELATIONSHIPS environment variable, which contains a base64 encoded JSON blob.
We need to ensure that we expose the correct information and credentials about the services we configure.

Example of decoded blob:

{
  "cache": [
    {
      "service": "memcached",
      "ip": "169.254.30.132",
      "hostname": "aulc4mtgtpdll5phtb3eioygey.memcached.service._.fr-3.platformsh.site",
      "cluster": "ohppb3vrezyog-master-7rqtwti",
      "host": "cache.internal",
      "rel": "memcached",
      "scheme": "memcached",
      "type": "memcached:1.6",
      "port": 11211
    }
  ],
  "database": [
    {
      "username": "user",
      "scheme": "mysql",
      "service": "mysqldb",
      "fragment": null,
      "ip": "169.254.118.116",
      "hostname": "gzanmenz3vkkimeol5i54acinm.mysqldb.service._.fr-3.platformsh.site",
      "public": false,
      "cluster": "ohppb3vrezyog-master-7rqtwti",
      "host": "database.internal",
      "rel": "mysql",
      "query": {
        "is_master": true
      },
      "path": "main",
      "password": "",
      "type": "mysql:10.2",
      "port": 3306,
      "host_mapped": false
    }
  ]
}

hostname, port, path (DB name), username, password, etc... should get the corresponding for the DDEV database, e.g. (values presented below are examples only, they may differ from real values from DDEV):

{
  "cache": [
    {
      "service": "memcached",
      "ip": "17.20.0.5",
      "hostname": "memcached",
      "cluster": "ddev-memcached-container",
      "host": "memcached",
      "rel": "memcached",
      "scheme": "memcached",
      "type": "memcached:1.6",
      "port": 11211
    }
  ],
  "database": [
    {
      "username": "db",
      "scheme": "mysql",
      "service": "mysqldb",
      "fragment": null,
      "ip": "172.20.0.4",
      "hostname": "db",
      "public": false,
      "cluster": "ddev-db-container",
      "host": "db",
      "rel": "mysql",
      "query": {
        "is_master": true
      },
      "path": "db",
      "password": "db",
      "type": "mariadb:10.4",
      "port": 3306,
      "host_mapped": false
    }
  ]
}

The JSON value should then be encoded in base64:

ewogICJkYXRhYmFzZSI6IFsKICAgIHsKICAgICAgInVzZXJuYW1lIjogImRiIiwKICAgICAgInNjaGVtZSI6ICJteXNxbCIsCiAgICAgICJzZXJ2aWNlIjogImRiIiwKICAgICAgImZyYWdtZW50IjogbnVsbCwKICAgICAgImlwIjogIjE3Mi4yMC4wLjQiLAogICAgICAiaG9zdG5hbWUiOiAiZGRldi1teWFwcC1kYiIsCiAgICAgICJwdWJsaWMiOiBmYWxzZSwKICAgICAgImNsdXN0ZXIiOiAiIiwKICAgICAgImhvc3QiOiAiZGRldi1teWFwcC1kYiIsCiAgICAgICJyZWwiOiAibXlzcWwiLAogICAgICAicXVlcnkiOiB7CiAgICAgICAgImlzX21hc3RlciI6IHRydWUKICAgICAgfSwKICAgICAgInBhdGgiOiAiZGIiLAogICAgICAicGFzc3dvcmQiOiAiZGIiLAogICAgICAidHlwZSI6ICJtYXJpYWRiOjEwLjQiLAogICAgICAicG9ydCI6IDMzMDYsCiAgICAgICJob3N0X21hcHBlZCI6IGZhbHNlCiAgICB9CiAgXQp9

The information exposed is up to the service (each service has a dedicated page, e.g. MariaDB).

Services to configure and to expose in $PLATFORM_RELATIONSHIPS

• MariaDB / MySQL
• Postgres
• Redis
• Memcached
• RabbitMQ

Properties in the Relationship JSON object

Each service has its own set of properties, but most are common.
All documented properties must be present, even if they are not used in DDEV.

Meaningful Properties

Properties that must be present, but can be left with default values

In Platform.sh containers, /app/.global/bin is always in the $PATH.
This is the directory where custom binaries may be placed, like the ones downloaded using the Symfony template (see Symfony Cloud configurator and downloaded tools)

In a basic Platform.sh project, $PATH contains the following:

/app/vendor/bin:/app/.global/bin:/app/.global/composer/composer/vendor/bin:/app/.global/vendor/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

This might be related to #53 , but the environmental variable PLATFORM_RELATIONSHIPS is not present in my ddev application container after upgrading to ddev-platformsh 0.5.0 and performing a ddev restart

gilzow@batcon-ddev-test-4-web:/var/www/html$ printenv | grep RELATIONSHIPS
gilzow@batcon-ddev-test-4-web:/var/www/html$ 

Other PLATFORM_* environmental variables (e.g. PLATFORM_ROUTES, PLATFORM_MOUNTS, PLATFORM_DIR, etc.) are present.

Kicked off from #81

As we advance this add-on, we should document which Platform.sh-provided Environmental variables have been implemented and are available inside of DDEV.

I hadn't been exposed to anything but deploy hooks, but there are also build and post-deploy hooks, docs at https://docs.platform.sh/create-apps/hooks/hooks-comparison.html

It would be nicer if each upstream hook was a separate item instead of how they're currently all bundled together.

We can't support multiple databases at this point so we should check in the add-on if they have them.
There are two ways to specify multiple databases,

1. Multiple schemas
2. Multiple relationships

Check both.

Hi @rfay
i can't get my Symfony project to be configured using ddev addon.
This is what i get from the command line :

flovntp@VNTP-Book-2 PlatformSH % platform get 4qqp5j5vtvnom    
Selected environment: Main (main) (type: production) (by default)
Directory (default: sfcon-bigfoot-workshop): sfcon2022-workshop-ddev
Downloading project SFCon - Bigfoot - workshop (4qqp5j5vtvnom)
  Cloning into '/Users/flovntp/Sites/Customers/PlatformSH/sfcon2022-workshop-ddev'...
  remote: counting objects: 1710, done.        
Receiving objects: 100% (1710/1710), 3.64 MiB | 6.90 MiB/s, done.
  Resolving deltas: 100% (1014/1014), done.

The project SFCon - Bigfoot - workshop (4qqp5j5vtvnom) was successfully downloaded to: sfcon2022-workshop-ddev

You can build the project with: 
    cd sfcon2022-workshop-ddev
    platform build
flovntp@VNTP-Book-2 PlatformSH % cd sfcon2022-workshop-ddev 
flovntp@VNTP-Book-2 sfcon2022-workshop-ddev % ddev start 
Failed to get project(s): could not find a project in /Users/flovntp/Sites/Customers/PlatformSH/sfcon2022-workshop-ddev. Have you run 'ddev config'? Please specify a project name or change directories: no .ddev/config.yaml file was found in this directory or any parent
flovntp@VNTP-Book-2 sfcon2022-workshop-ddev % ddev get platformsh/ddev-platformsh
Unable to get project(s) [platformsh/ddev-platformsh]: could not find a project in /Users/flovntp/Sites/Customers/PlatformSH/sfcon2022-workshop-ddev. Have you run 'ddev config'? Please specify a project name or change directories: no .ddev/config.yaml file was found in this directory or any parent

Let me know if you need me to grant you access to this project, it's the SFCon workshop that we will handle with Sylvain.

note: ddev start is just a fail try, to be sure that ddev can't start as it is.

Hi,

I've got an issue while pulling my Ibexa project (Symfony) from Platform.sh.

This is steps to reproduce (maybe i did something wrong)....

1. platform get lg4gpxi5g22he
2. cd vntp
3. brew unlink ddev && brew install --HEAD --fetch-head drud/ddev/ddev (because i had already ddev installed and discover that i needed to install the new version)
4. ddev config
5. ddev get platformsh/ddev-platformsh

And this is the error i get

could not process pre-install action '#ddev-nodisplay
#todo: This simplistic approach doesn't work for postgres; volume name is different
#and the database type file is different too
if docker volume ls | grep ${DDEV_PROJECT}-mariadb && docker run --rm -w /db -v ${DDEV_PROJECT}-mariadb:/db busybox cat db_mariadb_version.txt; then
  export current_db_version="$(docker run --rm -w /db -v ${DDEV_PROJECT}-mariadb:/db busybox cat db_mariadb_version.txt)"
  if [ -z "${current_db_version}" ]; then
    echo "something went wrong, current_db_version is empty" && false
  fi
  {{ $dbheader := index (split ":" .platformapp.relationships.database) "_0" }} 
  {{ $dbtype := replace "postgresql" "postgres" (get (get .services $dbheader) "type") }}
  # echo "dbheader={{$dbheader}} dbtype={{$dbtype}} "
  export upstream_db="{{ regexReplaceAll "oracle-" (regexReplaceAll ":.*$" $dbtype "") "" }}:{{ regexReplaceAll "^.*:" $dbtype "" }}"
  echo "Current db is ${current_db_version/_/:} (${current_db_version})"
  echo "New db is ${upstream_db}"
  if [ "${current_db_version/_/:}" != "${upstream_db}" ]; then
    printf "There is an existing database in this project that doesn\'t match the upstream database type.\nPlease back up this database and then \"ddev delete\" so the new database can be created.\n"
    false
  else
    echo "database versions match: ${current_db_version/_/:}=${upstream_db}"
  fi
fi
': Unable to run action set -eu -o pipefail
#ddev-nodisplay
#todo: This simplistic approach doesn't work for postgres; volume name is different
#and the database type file is different too
if docker volume ls | grep ${DDEV_PROJECT}-mariadb && docker run --rm -w /db -v ${DDEV_PROJECT}-mariadb:/db busybox cat db_mariadb_version.txt; then
  export current_db_version="$(docker run --rm -w /db -v ${DDEV_PROJECT}-mariadb:/db busybox cat db_mariadb_version.txt)"
  if [ -z "${current_db_version}" ]; then
    echo "something went wrong, current_db_version is empty" && false
  fi
   
  
  # echo "dbheader=mysqldb dbtype=mariadb:10.4 "
  export upstream_db="mariadb:10.4"
  echo "Current db is ${current_db_version/_/:} (${current_db_version})"
  echo "New db is ${upstream_db}"
  if [ "${current_db_version/_/:}" != "${upstream_db}" ]; then
    printf "There is an existing database in this project that doesn\'t match the upstream database type.\nPlease back up this database and then \"ddev delete\" so the new database can be created.\n"
    false
  else
    echo "database versions match: ${current_db_version/_/:}=${upstream_db}"
  fi
fi
: exit status 1, output=local     vntp-mariadb
Unable to find image 'busybox:latest' locally
latest: Pulling from library/busybox
50783e0dfb64: Pulling fs layer
50783e0dfb64: Verifying Checksum
50783e0dfb64: Download complete
50783e0dfb64: Pull complete
Digest: sha256:ef320ff10026a50cf5f0213d35537ce0041ac1d96e9b7800bafd8bc9eff6c693
Status: Downloaded newer image for busybox:latest
mariadb_10.3
Current db is mariadb:10.3 (mariadb_10.3)
New db is mariadb:10.4
There is an existing database in this project that doesn't match the upstream database type.
Please back up this database and then "ddev delete" so the new database can be created.

So i executed ddev delete && ddev get platformsh/ddev-platformsh but same error occurs.

Am i doing something wrong ?

@rfay I give you access to my PSH project (VNTP, dev branch), let me know if the invite expired, i'm in vacation but i'm able to connect and invite you again.

Install global Python 2 and Python 3 dependencies in the container, as configured in .platform.app.yaml

It is time to return to the automated tests, preferably trying to do something live.

DDEV in recent versions checks on start and config to make sure the configured database type/version is the same as the actual database type (if one exists).

So if people create a project (or it already exists), perhaps with the default mariadb:10.4 type, and then do a ddev get and the .platform/services.yml provides a different type or version, then people get a fairly ugly message.

Failed to start WordPress-Composer-Template-Tester: Unable to start project WordPress-Composer-Template-Tester because the configured database type does not match the current actual database. Please change your database type back to mariadb:10.4 and start again, export, delete, and then change configuration and start. To get back to existing type use 'ddev config --database=mariadb:10.4' and then you might want to try 'ddev debug migrate-database mariadb:10.5', see docs at https://ddev.readthedocs.io/en/latest/users/extend/database_types/

Since that message is buried at the bottom of loads of incomprehensible complaints, it's annoying and difficult for a first-time user.

php ./drush/platformsh_generate_drush_yml.php (hook provided by drupal template) fails with "failed to find a site URL" on ddev.

DDEV provides a hosting provider config for Platform.sh.

This should be delegated to the add-on, with additional features:

• Interactive setup (See #3 )
  • CLI Token, with choice to store it globally (default) or at project level. Discard if already set
  • Project ID, unless the local project is already configured (platform project:info id)
  • Default environment (platform project:info default_branch)
  • Possible to cancel and re-run the setup later
  • Choice to pull the database and mounts from PSH, based on the current environment
    • platform env / platform environment:info id

Using the latest HEAD version of DDEV, running ddev get platformsh/ddev-platformsh fails:

Error Details

template: processAction:10:84: executing "processAction" at <.services.dbmysql.type>: invalid value; expected string

could not process pre-install action '#ddev-nodisplay
#todo: This simplistic approach doesn't work for postgres; volume name is different
#and the database type file is different too
if docker volume ls | grep ${DDEV_PROJECT}-mariadb; then
  export current_db_version="$(docker run --rm -w /db -v ${DDEV_PROJECT}-mariadb:/db busybox cat db_mariadb_version.txt)"
  if [ -z "${current_db_version}" ]; then
    echo "something went wrong, current_db_version is empty" && false
  fi
  export upstream_db="{{ regexReplaceAll "oracle-" (regexReplaceAll ":.*$" .services.dbmysql.type "") "" }}:{{ regexReplaceAll "^.*:" .services.dbmysql.type "" }}"
  echo "Current db is ${current_db_version/_/:} (${current_db_version})"
  echo "New db is ${upstream_db}"
  if [ "${current_db_version/_/:}" != "${upstream_db}" ]; then
    printf "There is an existing database in this project that doesn\'t match the upstream database type.\nPlease back up this database and then \"ddev delete\" so the new database can be created.\n"
    false
  else
    echo "database versions match: ${current_db_version/_/:}=${upstream_db}"
  fi
fi
': could not parse/execute action 'set -eu -o pipefail
#ddev-nodisplay
#todo: This simplistic approach doesn't work for postgres; volume name is different
#and the database type file is different too
if docker volume ls | grep ${DDEV_PROJECT}-mariadb; then
  export current_db_version="$(docker run --rm -w /db -v ${DDEV_PROJECT}-mariadb:/db busybox cat db_mariadb_version.txt)"
  if [ -z "${current_db_version}" ]; then
    echo "something went wrong, current_db_version is empty" && false
  fi
  export upstream_db="{{ regexReplaceAll "oracle-" (regexReplaceAll ":.*$" .services.dbmysql.type "") "" }}:{{ regexReplaceAll "^.*:" .services.dbmysql.type "" }}"
  echo "Current db is ${current_db_version/_/:} (${current_db_version})"
  echo "New db is ${upstream_db}"
  if [ "${current_db_version/_/:}" != "${upstream_db}" ]; then
    printf "There is an existing database in this project that doesn\'t match the upstream database type.\nPlease back up this database and then \"ddev delete\" so the new database can be created.\n"
    false
  else
    echo "database versions match: ${current_db_version/_/:}=${upstream_db}"
  fi
fi
': template: processAction:10:84: executing "processAction" at <.services.dbmysql.type>: invalid value; expected string

DDEV version info

{
  "level": "info",
  "raw": {
    "DDEV version": "vHEAD-ef00de8",
    "architecture": "arm64",
    "build info": "BUILDINFO should have new info",
    "db": "drud/ddev-dbserver-mariadb-10.3:v1.19.3",
    "dba": "phpmyadmin:5",
    "ddev-ssh-agent": "drud/ddev-ssh-agent:v1.19.0",
    "docker": "20.10.14",
    "docker-compose": "v2.5.1",
    "docker-platform": "docker-desktop",
    "mutagen": "0.14.0",
    "os": "darwin",
    "router": "drud/ddev-router:v1.19.3",
    "web": "drud/ddev-webserver:20220619_add_phpstorm_coverage_directory"
  },
  "time": "2022-06-23T10:35:05+02:00"
}

Platform files

platform_files.zip

I was going to add it to the Dockerfile, but this should probably go into config.platformsh.yaml and while I was going to try a quick edit, I think #39 needs to be addressed first.