Epic: Automated workspace creation (e.g. in CI pipelines) via Public API

[loujaybee]

Allow users to create a workspace dynamically, via API.

In scope:

• HTTP endpoint

Relates to:

• Epic: Private beta of initial public APIs #10798
• Epic: Prebuild Public APIs #15213
• Epic: Resource Usage (Billing) Public APIs #11335
• Epic: Automate off + onboarding via Public API (users, teams & projects) #10799
• Epic: Personal Access Tokens #14280
• Epic: Create external workspace dashboards or clients (e.g. CLI or IdP) via Public API #10427
• Epic: Service accounts (Auth tokens not tied to users) #15419
• Epic: Foundations for Fine Grained Authorization #15632
• Epic: Automated workspace creation (e.g. in CI pipelines) via Public API #15829

Callout: 👋 Are you interested in this feature? We would be interested to talk to you.

Public API in private beta: See this issue for more details.

[loujaybee]

Moving to future backlog, the private beta remains open, but we're waiting on more customer feedback and input before we progress the various Public API initiatives.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[loujaybee]

Related use case from the community:

I'm the maintainer of DDEV, which has explicit support for gitpod, and people really like using DDEV there. However, unlike all the other environments we support, we have never figured out a way to do automated testing on gitpod with DDEV's test suite. We have automated testing going at every push on macOS (arm64 and amd64), Linux, Windows, WSL2, everywhere. But not on gitpod. The other day a user just randomly tested DDEV HEAD and found that the gitpod setup was broken. I'm working on a fix. But is there any way we could automatically test at least some of DDEV on Gitpod?

My response...

My immediate reaction / thought would be to suggest configuring a workspace image, pulling that image, and running the scripts. That does look quite like what the github action that @lmilbaum shared is doing... unless I'm missing something. However, from talking to @rfay it sounds like this wouldn't be comprehensive enough. In that case, I'd agree with @ghost that programatically starting a workspace would seem like the best bet here via an API, and asserting on the result.

If we allow that API to pass configuration, like environment variables through to the workspace, that would allow you to conditionally run the tasks that are tests, and then that all tasks exit cleanly. However, having something more native into the .gitpod.yml would also be nice, potentially where you could mark which tasks would run in a test scenario, and which wouldn't. We'd also need to consider how the API returns the successful assertion of the workspace start.

Related to:

• In docker container, second process cannot write to /proc/1/fd/1 #17551