svenefftinge
Repos
298
Followers
303
Following
74

Gitpod automates the provisioning of ready-to-code development environments.

10129
908

Ready to use docker images for Gitpod workspaces

413
294

Events

Build previewctl using GitHub actions and enable job on main

Outputs are strings so we have to check explicitly

Fix delete-preview action

Temporarily build the docker image on every build

[admin] add phone number to user page

[ws-manager-mk2] Configure health probes and leader election

[spicedb] Add network policy

[spicedb] Disable remote telemetry

[spicedb] Remove duplicate DB_HOST env var for db-waiter

[spicedb] Fix migrations service account name

[grafana] Cleanup server component dashboard

[dashboard] user visible rename team->organization

remove org slug

Created at 1 day ago

remove org slug

Created at 1 day ago
pull request opened
[Dashboard] Deslugging

Description

Related Issue(s)

Fixes #

How to test

Release Notes

Documentation

Build Options:

  • [ ] /werft with-github-actions Experimental feature to run the build with GitHub Actions (and not in Werft).
  • [ ] leeway-no-cache leeway-target=components:all
  • [ ] /werft no-test Run Leeway with --dont-test

Preview Environment Options:

  • [ ] /werft with-local-preview If enabled this will build install/preview
  • [x] /werft with-preview
  • [ ] /werft with-large-vm
  • [ ] /werft with-gce-vm If enabled this will create the environment on GCE infra
  • [ ] /werft with-integration-tests=all Valid options are all, workspace, webapp, ide, jetbrains, vscode, ssh
Created at 1 day ago
create branch
svenefftinge create branch se/deslugging
Created at 1 day ago
issue comment
[dashboard] user visible rename team->organization

/werft run

Created at 1 day ago

[dashboard] user visible rename team->organization

Created at 1 day ago
issue comment
[Dashboard] Remove slugs for orgs (rely on a DB-level setting)

I would not require the prebuilds to be nested in the project URLs if we use UIDs.

Created at 1 day ago
issue comment
[Dashboard] Remove slugs for orgs (rely on a DB-level setting)

Sounds good! I would love to do that later once we feel like the URL needs to contain the project name as well? Seems like we could easily add such a redirect later. unlike notion, I believe the context in gitpod (i.e. project name) is very visible.

Created at 1 day ago
issue comment
[Dashboard] Remove slugs for orgs (rely on a DB-level setting)

I'm tempted to use the project id instead of a name/slug. That way we could tell users to switch to another org (and optionally don't ask again) if they are clicking a link to that project. Using the name there might be confusion if the same name is used in different orgs. wdyt?

Created at 1 day ago

[dashboard] user visible rename team->organization

Created at 1 day ago
issue comment
[dashboard] user visible rename team->organization

Currently, All Projects have a static URL with <team> (i.e. /t/<team>/<project>). Related docs. This should also be changed because in Docs We need to mention the updated slug URL (/o/<org>/<project>).

Related Unchanged Files:

I'll look at those URLs as part of https://github.com/gitpod-io/gitpod/issues/16053

Created at 1 day ago
issue comment
[dashboard] user visible rename team->organization

/werft run with-clean-slate-deployment

Created at 1 day ago

[dashboard] user visible rename team->organization

Created at 1 day ago
issue comment
[server] synchronize migration and only migrate users without chargebee plan

/werft run with-clean-slate-deployment

Created at 2 days ago
issue comment
[dashboard] user visible rename team->organization

/werft run with-clean-slate-deployment

Created at 2 days ago
opened issue
[Dashboard] Remove slugs for orgs (rely on a DB-level setting)

We are moving away from orgs/teams being a secondary folder in which you maintain projects, towards orgs that act as a globally active context in which a user interacts with Gitpod. (see #15980 )

To that end it doesn't make sense to keep the slugs per org, instead we can allows a searchParam (in any dashboard URL) that will set the currently active org. The currently active org should be set in the browser session as well as in the settings, so that all existing APIs can obtain the active org if it is not passed explicitly (we can eventually move to explicitly passing the org as an argument).

Operations such as create workspace would use whatever context is set. Starting existing workspaces should not use the global setting but restart the workspace in the org the workspace belongs to.

Created at 2 days ago