Gitpod Classic will shut down, making Drupalpod obsolete

Created on 20 January 2025, 3 months ago

What is Drupalpod?

Drupalpod is a much-loved toolset for Drupal.org that allows easy configuration of a Drupal core or contrib issue Merge Request (MR) by visiting the issue page and specifying a configuration. The Drupalpod browser extension allows choosing a Drupal core version and other configuration options and then launches a Gitpod instance with that code and configuration so people can immediately test or improve an MR.

Gitpod (Classic) is a system that gives users a Docker-capable Linux Virtual Machine (VM) whose UI is presented via Visual Studio Code (VS Code). This is a perfect environment for the local development tool DDEV, so DDEV is used to run a "local" site built on the code specified by Drupalpod's configuration UI. Gitpod Classic provides Docker-In-Docker, which is required to use normal Docker capabilities in a virtiualized system. (It uses nested virtualization.)

Gitpod also provides the git client and git capabilities, perfect for contributing to Drupal.org projects. And the Drupal.org team was able to implement SSO integration with drupal.org so that users could push code to a Drupal.org issue fork without password authentication.

Drupalpod with this combination of features provides a way for any Drupal contributor to select an issue and have a full "local" development environment reflecting a Drupal.org issue in a a minute or two, without changing their local computer or even caring what their local computer is, as long as it can run a browser.

Ofer Shaal β†’ created Drupalpod and has maintained it with some community help since its beginning. DDEV has implemented a number of features in order to help run DDEV on Gitpod for Drupalpod.

Gitpod and the Drupal.org team were able to implement authentication so that a Drupal.org user could authenticate from Gitpod without extra steps. This special feature reduced friction for users.

Gitpod Classic is going away in April, 2025

Unfortunately, Gitpod has announced that it is sunsetting its "Gitpod Classic" product, which has been the fundamental tool used by Drupalpod, and that Gitpod will no longer be available after April 1, 2025.

Drupalpod's Chrome Extension is obsolete

The current Drupalpod Chrome Extension is using obsolete features of the Chrome Web Store, so there's a warning that it will be taken down soon.

What does the Drupal Community do to replace or change Drupalpod?

As-is, Drupalpod won't be usable after April, 2025.

Option: Replace with a Gitpod-like system

A variety of similar hosted systems are out there on the Internet, including a number that use VS Code as their web UI. Some of these provide just the VS Code UI, others provide a VM like Gitpod has done, and some make Docker capabilities available.

rfay has had meetings with the Gitpod Flex team, who offer a self-hosted option that should run on AWS, for example, and also with the Devpod team, which has a similar offering. Neither of these teams seem to have a self-hosted AWS product that has repeatable behavior at this time. (Neither was able to demonstrate a running system or coach rfay to do so.)

However, GitHub Codespaces is a very similar system to Gitpod, with the same VM capability, Docker capability, and VS Code UI. The "free plan" limits for Codespaces are a bit more limited than Gitpod's, but it works fine for running any Drupal project with DDEV, and in essence behaves just like Gitpod, except for the deployment stage, where Gitpod had more features that could set everything up during startup. A scripted setup could do what Drupalpod currently does with Gitpod though.

Option: Let contributors learn enough of Drupal.org and git to navigate contribution themselves, using their own local environment.

Probably most Drupal contributors already use git and the Drupal Gitlab instance and the Drupal.org issue queue to do what they need. There's a nontrivial learning curve for understanding the relationship between Drupal.org issues, Gitlab issue forks, Git, and DDEV in order to do this, but it's a very solid foundation once people understand these things. However, in a first-time contributor situation, that's a lot to learn and unfortunately overwhelming.

Option: Revive the DDEV Quicksprint project

Before Drupalpod existed and came to be used a contribution events, DDEV's Quicksprint project was used. A per-OS tarball including everything needed for development with DDEV was provided and people were encouraged to download it in advance, or it was provided via a flash drive at contribution events. This had the advantage of not requiring significant bandwidth on poor convention WIFI systems, but also left contributors needing to navigate all the features of Drupal.org and git and using DDEV. All that was before the introduction of issue forks, which add another entire degree of complexity.

Possible goals of a future Drupalpod

  1. Allow anyone to get a running environment that represents an MR in a core or contrib Drupal issue using a few clicks or selections.
  2. Provide an on-ramp for new contributors and Drupal contribution events.
  3. Provide a UI entirely in the browser, so no configuration of the user's system is required.

Thoughts about implementation

  • Currently we have a fairly high-maintenance browser extension (or three) that detects the MR in use from the page a user is visiting, and then generates a set of arguments with which to launch a Gitpod instance.
  • It would be possible for another tool or technology to do that examination and then provide a way to check out the needed code. DDEV could then be used as it is used now to run the Drupal project with the proper code. Ideas for this might include:
    • A script that, given an issue page, would use Drupal.org API or page scraping to determine the proper configuration. One advantage of a script would be that it wouldn't be tied to a particular environment as we currently are, and could be used on a local machine or anywhere DDEV was supported. GitHub Codespaces could be configured this way.
    • A browser extension could generate a script to do the same thing.
    • A browser extension might be able to launch a Codespaces instance, although we haven't studied how this could best be done.
    • A bookmarklet might be able to do some of the same functionality.

References

πŸ“Œ Task
Status

Active

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States rfay Palisade, CO, USA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @rfay
  • πŸ‡ΊπŸ‡ΈUnited States rfay Palisade, CO, USA
  • πŸ‡ΊπŸ‡ΈUnited States rfay Palisade, CO, USA
  • πŸ‡ΊπŸ‡ΈUnited States rfay Palisade, CO, USA

    There is a BoF Scheduled for this at Drupalcon Atlanta, 04:00pm - 04:30pm Tuesday, March 25, 2025, join us!

  • πŸ‡ΊπŸ‡ΈUnited States mradcliffe USA

    I made progress on a DrupalPod quicksprint on my fork ("Option: Revive the DDEV Quicksprint project"), and I think this is a good fallback to "Option: Replace with a Gitpod-like system". We can't do "Option: Let contributors learn enough of Drupal.org and git to navigate contribution themselves, using their own local environment." for on-site contribution events because we'll destroy the network or get auto-blocked, but that option is the recommended development environment for experienced developers.

    Anyway I'm able to run ./start_sprint.sh to spin up DrupalPod locally.

    My to do list:

    - I need to bring in my work from mradcliffe/docker-core-sprint to package up Docker images since the ddev images tarball is no longer distributed. These need to be both the amd64 and arm64 images (oof).
    - Update documentation regarding system requirements.
    - Rename sprint to contribution or contrib.
    - Get some upstream hacks into DrupalPod (merge requests created) - πŸ“Œ Running project_core locally runs composer outside of ddev Active
    - Clean up use of DrupalPod environment variables. It would be nice to contribute dot env support back to DrupalPod.
    - Get more USB drives for the Mentor Box.

  • πŸ‡ΊπŸ‡ΈUnited States chrisfromredfin Portland, Maine

    I know in the Slack channel people were discussing alternatives of Drupal hosting along the lines of SimplyTest.ME, Tugboat, etc. The fundamental difference there being that what is missing is the contributing aspect - the full IDE-in-browser experience.

    To that, I know that while we have concerns about things "not staying around" (as GitPod Classic didn't, for example), I may recommend Drupal Forge as something to at least have a discussion with/about. It DOES have the full-featured IDE, and we are close to these folks inside the Drupal Community.

    What I think is missing is the concerted effort to spin up code from an MR, for example. But that might be an easier lift for folks already working inside the IDE-in-browser space. ?

    I have no existing relationship or knowledge of them, except having seen a quick demo at DrupalCamp Asheville. But the conversations in Slack had me thinking.

    https://www.drupalforge.org/

  • πŸ‡ΊπŸ‡ΈUnited States rfay Palisade, CO, USA
  • πŸ‡ΊπŸ‡ΈUnited States rfay Palisade, CO, USA

    Updated OP to show that the Chrome extension is no longer obsolete, has been updated, so that's not a problem.

  • πŸ‡ΊπŸ‡ΈUnited States capellic Austin, Texas

    I imagine that Gitpod Desktop is not being considered because it only supports Apple silicon machines? https://www.gitpod.io/docs/flex/gitpod-desktop/overview

  • πŸ‡ΊπŸ‡ΈUnited States rfay Palisade, CO, USA

    @capelilic, not the problem with the new GitPod Flex is that it needs to be installed on your machine (and only supports mac at this point). So it has no advantage over a Docker/DDEV setup. We had a meeting with them to get them to demonstrate it working self-hosted like on AWS, but they weren't able to get it going, although they made a big deal out of it. I'm really surprised they don't even support Intel macs.

  • πŸ‡ΊπŸ‡ΈUnited States capellic Austin, Texas

    Thanks @rfay.

  • πŸ‡ΊπŸ‡ΈUnited States rfay Palisade, CO, USA

    DrupalCon Atlanta BoF Results.

    My summary:

    Some thoughts from the BoF about future of DrupalPod:

    • Drupalpod actually has two uses: Just letting people contribute easily to Drupal, and as a great technique for contribution day at Drupal events. Those are related but somewhat different uses.
    • Ofer doesn't seem to have the passion for it any more.
    • Darren's generous contribution in making DrupalForge follow the DrupalPod platform may have a future, although it's a very different thing, not DDEV based, not Docker based, and doesn't use the practices we normally recommend. My own experience with it has been that it isn't performant enough to be usable, but I imagine this is a solvable problem.
    • @mradcliffe long maintained the quicksprint package, which is a way to build a full set of DDEV artifacts that can be pre-distributed or distributed via a flash drive or whatever. It worked back in the day, and Matthew has refreshed it already in a fork. It might not be easy to make "picker" that gets the right issue fork and all. So this gets DDEV and related tools, but doesn't necessarily simplify the overall contribution workflow. We used Quicksprint in the days before issue forks (and before WSL2, etc. etc)
    • There are systems like Gitpod that might be candidates for another look. GitHub Codespaces is fully supported by DDEV, if it's going to have a "picker" browser extension like Drupalpod it would probably have to be implemented a different way. Coder has been recommended, but I don't think there's a free community-usable version.
    • Mike Anello asked what a MVP might be. We don't know what it might be or how we would accomplish it, or who has the passion for it.

    The recording of the BoF is attached.

  • πŸ‡ΊπŸ‡ΈUnited States mradcliffe USA

    Thanks for recording the discussion, @rfay!

Production build 0.71.5 2024