Get project id from existing platform config files

[bserem]

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: https://github.com/platformsh/ddev-platformsh/issues/7

[rfay]

Thanks for taking it for a spin, really appreciate your comments!

Unfortunately .platform/local/project.yaml is created by the platform cli after it knows the project ID.

There are various ways for the platform CLI to figure out the project and environment, but they mostly depend on on the git remote, which only works for git repos hosted on platform, not repos on github or gitlab.

So I struggled with this and never came up with an authoritative answer better than just asking the user. Would love any suggestions of course.

[bserem]

I see, in that case maybe close the issue (we can re-open) or flag it as "really nice to have" or something? After all, it is a nice to have and a one-time thing rather than something critical.

I need to create a platform project from scratch to fully understand the procedure but I don't see happening anytime soon.

[rfay]

Closing, but it's a lovely pursuit, and I think everybody thought there would be a way, and there would have been in the days before github and gitlab support.

Would love to hear how your use the the add-on worked otherwise.

[bserem]

In the projects I encountered .platform/local/project.yaml was commited and it was available in the github repo too. That's what triggered the thought.

Again, I only started working with Platform 3 weeks ago. So for sure not fully up-to-date with the details.

[rfay]

Yeah, the README in .platform/local tells all:

.platform/local
===============

This directory is where the Platform.sh CLI stores configuration files, builds, and
other data to help work with your project locally.

It is not used on remote environments at all - the directory is excluded from
your Git repository (via .git/info/exclude).

[lolautruche]

We may check if the file is already there, and if so use the project ID. That can indeed be useful when it's commited

[rfay]

I think that making discoverability of the project/environment from the repo/config should be a goal for sure. Where would we prod that along @lolautruche ?

[bserem]

I'm willing to give this a try. I can put it on low-prio for this/next week. By looking at the code it should be ok to check this on installation of the extension and copy the correct value to .ddev/config.yaml.

[bserem]

@rfay care to re-open this? It's not top priority but my guess is it's not far away now

[rfay]

Closing for now, happy to reopen when you get back to it. I don't personally think it can be done reliably.

[gilzow]

I don't personally think it can be done reliably.

@rfay can you elaborate?

If the person retrieves the project with the platform.sh CLI tool via platform get <projectid> it's automatically added as part of the setup. If the project is set up with an external (e.g. github, gitlab) integration, and they they clone from that source, it can still be added via platform project:set-remote. I would guess for most people that need to work with platform.sh, they'll set the remote to reduce the amount of effort required to interact with the project otherwise (ie having to add -p <projectid> to every command).

The only scenario I can think of where the project isnt set up (ie .platform/local/project.yaml isn't available) is when there's an external integration on the project, the person has cloned from the external source (vs platform get), and either doesn't have access to the platform project directly, or is running ddev commands before setting up the remote.

In any of the above scenarios, I would think the add-on could still check for the file's existence and use it if available.

[rfay]

You're right, if people use platform get on the host side to populate the code. I guess I always am biased toward traditional git techniques, and if people check out with git, this does not work.

And of course DDEV does not require people to install the platform cli at all on the host, because it's in the web container.

However, if we change the expectation slightly to tell people to install the CLI and get the project with platform cli then this would work great.

[gilzow]

But this is the platformsh add-on, not DDEV proper. If they're using this add-on, then we should be able to safely assume they're doing so because they're trying to set up a platform.sh project in DDEV.

There's no way for them to easily clone a project directly from platform.sh without the cli. If they didn't use the CLI to clone the project that leaves us with the scenario of them cloning a project from an integration source where that project has an integration created. And in either case, the add-on should still be able to cheaply check for the existence of a file and use it if it's available.

There are various ways for the platform CLI to figure out the project and environment, but they mostly depend on on the git remote, which only works for git repos hosted on platform, not repos on github or gitlab.

If I remember correctly, that's a fail-safe if the .platform/local/project.yaml has been removed or corrupted. And in that case, the cli regenerates the .platform/local/project.yaml file after running a command. We can ask dawkins for a definitive clarification, but from what I know, .platform/local/project.yaml is the primary source for a project's ID.

Alternatively, what about starting a container with the CLI installed, and then using it to retrieve and configure all the necessary information from Platform.sh? This way you could re-use the cli's autocomplete abilities on projects.

[rfay]

But this is the platformsh add-on, not DDEV proper. If they're using this add-on, then we should be able to safely assume they're doing so because they're trying to set up a platform.sh project in DDEV.

I don't agree. I would be using git, and this is gitignored. But that doesn't mean we can't encourage people to install and use the platform command to do the initial checkout.

There's no way for them to easily clone a project directly from platform.sh without the cli. If they didn't use the CLI to clone the project that leaves us with the scenario of them cloning a project from an integration source where that project has an integration created. And in either case, the add-on should still be able to cheaply check for the existence of a file and use it if it's available.

I don't agree with this either. I imagine most people don't want their code hosted by Platform in the first place, so have it on github or gitlab. And it's easy to get the git URL and clone; it was the only way I'd done it until lately.

Alternatively, what about starting a container with the CLI installed, and then using it to retrieve and configure all the necessary information from Platform.sh? This way you could re-use the cli's autocomplete abilities on projects.

The web container already has the platform tool installed, and if they've done the global setup, it knows all the projects. But... unless the remote is as expected, autocomplete doesn't work either.

I think if we just encourage people to check out with platform instead of git we'll be a step closer.

[bserem]

In our case we use git (lab/hub/whatever) but we opted to commit .platform/local/project.yaml in the repository rather than that ignoring it.

Encouraging people to checkout from platform (instead of git) means asking them to change a lot of their workflows and tools. I feel this would be harder to achieve and harder to convince people.

[lolautruche]

Another approach I can see would be to use platform project:info id --no-interaction command, whether on the host (if the command is present) or in the container. This command directly displays the project ID if it's a valid PSH project, with return code 0. If it's not a PSH project, return code is 2, and displays an error (that we can probably hide).

[rfay]

The problem remains that it's not possible to get project:info predictably and reliably.

[rfay]

@gilzow and I just talked, here's a strategy:

1. Try to get the file. If it exists, use it. This would work for platform-tool checked out repos, and for @bserem 's situation
2. Ask if we don't have it.
3. In the future, use ddev-webserver or another container to run platform tool and give them choice of project ids.