When Auth is enabled, and user logs in, there is always a valid workspace
When Auth is disabled, I have not noticed if the local user is associated with some default workspace. If not, I think we should do this.
This way, settings (and some secrets are always workspace global.
Today, it looks like we have some code paths where "global" scope is considered when workspaceId is null. This is causing some issues.
For example. I have Auth enabled. After login, use "Global" scope in the new setup UI and configure GitHub token. I complete the setup. I see that Github token is added with "global" scope (this has current workspaceId attached)
Now, I go to repos and try to add a new repo. It is unabled to add a repo as it doesn't find a GITHUB_TOKEN with workspaceId is Null. Infact, when I go to settings now, it says that there is no GITHUB_TOKEN, even though I configured it via /setup.
Main question is: is there a use case for "global" scope values with workspaceId is null - that is some config common to all workspaces ? I thought workspaces are like "namespaced" config.
One scenario where I see this makes sense today is in ticket providers. Background sync jobs don't have workspace context and ticket provider doesn't have workspace id. Why not have workspaceId for ticket providers as well ? If the usecase for workspaces is for different teams to use the same shared infra, then ticket provider with workspace id makes sense.
I am running into a side-effect issue. When we select and create a repo using /setup page, we have a ticket integration for GitHub (enabled by default). In addition to creating a ticket provider, it also adds a secret with ticket-provider: with the value that of github token entered in earlier screen (and with workspace_id as current workspace id).
But this is missing when I add a new repo from Repo UI and then add a ticket provider for this repo and results in sync failing (trying to find a github token)
When Auth is enabled, and user logs in, there is always a valid workspace
When Auth is disabled, I have not noticed if the local user is associated with some default workspace. If not, I think we should do this.
This way, settings (and some secrets are always workspace global.
Today, it looks like we have some code paths where "global" scope is considered when workspaceId is null. This is causing some issues.
For example. I have Auth enabled. After login, use "Global" scope in the new setup UI and configure GitHub token. I complete the setup. I see that Github token is added with "global" scope (this has current workspaceId attached)
Now, I go to repos and try to add a new repo. It is unabled to add a repo as it doesn't find a GITHUB_TOKEN with workspaceId is Null. Infact, when I go to settings now, it says that there is no GITHUB_TOKEN, even though I configured it via /setup.
Main question is: is there a use case for "global" scope values with workspaceId is null - that is some config common to all workspaces ? I thought workspaces are like "namespaced" config.
One scenario where I see this makes sense today is in ticket providers. Background sync jobs don't have workspace context and ticket provider doesn't have workspace id. Why not have workspaceId for ticket providers as well ? If the usecase for workspaces is for different teams to use the same shared infra, then ticket provider with workspace id makes sense.
I am running into a side-effect issue. When we select and create a repo using /setup page, we have a ticket integration for GitHub (enabled by default). In addition to creating a ticket provider, it also adds a secret with ticket-provider: with the value that of github token entered in earlier screen (and with workspace_id as current workspace id).
But this is missing when I add a new repo from Repo UI and then add a ticket provider for this repo and results in sync failing (trying to find a github token)