298
303
74
Gitpod automates the provisioning of ready-to-code development environments.
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
[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
[dashboard] user visible rename team->organization
/werft run
[dashboard] user visible rename team->organization
[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.
[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.
[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?
[dashboard] user visible rename team->organization
[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
[dashboard] user visible rename team->organization
/werft run with-clean-slate-deployment
[dashboard] user visible rename team->organization
[server] synchronize migration and only migrate users without chargebee plan
/werft run with-clean-slate-deployment
[dashboard] user visible rename team->organization
/werft run with-clean-slate-deployment
[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.
