Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding ConfigurationServiceAPI #19020

Merged
merged 17 commits into from
Nov 8, 2023
Merged

Adding ConfigurationServiceAPI #19020

merged 17 commits into from
Nov 8, 2023

Conversation

selfcontained
Copy link
Contributor

@selfcontained selfcontained commented Nov 6, 2023

Description

Adds the ConfigurationService api that is meant to be a replacement for existing Projects apis. Internally it uses the existing ProjectService. The following methods are included in this PR:

  • CreateConfiguration
  • GetConfiguration
  • ListConfigurations
  • DeleteConfiguration

Update* method(s) will be implemented in a followup PR.

The initial consumer of these endpoints will just be the new Repo Config UIs. Existing UI that uses the project apis will continue to use them and won't be migrated over these apis since they'll be removed once we release the repo config uis.

Summary generated by Copilot

🤖 Generated by Copilot at 9e5879e

This pull request adds the Configuration service to the public API, which allows managing project configurations composed of prebuild settings and workspace settings. It also adds the ability to search for projects by name or cloneUrl in the projectDb. It updates the public-api-converter and its tests to handle the new types related to the Configuration service. It generates the necessary files for the gRPC-Go, Connect-Go, and Connect-ES clients and servers from the configuration.proto file. It implements the ConfigurationServiceHandler interface in the configuration-service-api.ts file using the ProjectsService and the PublicAPIConverter.

Related Issue(s)

Fixes EXP-877

How to test

  • ListConfigurations and GetConfiguration are integrated into the Dashboard UI in this PR.
  • You can verify them by using the Repositories link from the Org Menu in the top left.
  • Create a new Config (still says project in the copy for now).
  • It should navigate you to the Detail page, which exercises the GetConfiguration method.
  • Navigate back to the list and ensure you see the new configuration, which exercises the ListConfigurations method.
  • Create/Delete will be integrated into the new UIs in followups.

Documentation

Preview status

Gitpod was successfully deployed to your preview environment.

Build Options

Build
  • /werft with-werft
    Run the build with werft instead of GHA
  • leeway-no-cache
  • /werft no-test
    Run Leeway with --dont-test
Publish
  • /werft publish-to-npm
  • /werft publish-to-jb-marketplace
Installer
  • analytics=segment
  • with-dedicated-emulation
  • workspace-feature-flags
    Add desired feature flags to the end of the line above, space separated
Preview Environment / Integration Tests
  • /werft with-local-preview
    If enabled this will build install/preview
  • /werft with-preview
  • /werft with-large-vm
  • /werft with-gce-vm
    If enabled this will create the environment on GCE infra
  • with-integration-tests=all
    Valid options are all, workspace, webapp, ide, jetbrains, vscode, ssh. If enabled, with-preview and with-large-vm will be enabled.
  • with-monitoring

/hold

@@ -16,6 +16,11 @@ import { Message } from "@bufbuild/protobuf";
import { ReactQueryDevtools } from "@tanstack/react-query-devtools";
import { FunctionComponent } from "react";
import debounce from "lodash.debounce";
// Need to import all the protobuf classes we want to support for hydration
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I swapped these to imports for consistency and I think it makes it a bit clearer what we're importing and why. It seems to work fine this way, not sure if there was another reason you had used require's @svenefftinge?

Normally I think imports are more desirable as they allow for static analysis (and allow for tree-shaking unused exports). In this case we're importing everything anyways, so that benefit is probably moot, but I think the consistency of imports at the beginning of the module is still valuable for readability. Happy to adjust back if we don't want that though.

string organization_id = 1;
string name = 2;
string clone_url = 3;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@svenefftinge I dropped the workspace/prebuild settings from this create request for now just to reduce some of the scope of the changes in here and not hold up the basics. I do think it would be nice to support though since you'd most likely want to set those during create if you were using this as a consumer of the api directly.

@selfcontained selfcontained marked this pull request as ready for review November 7, 2023 23:33
@selfcontained selfcontained requested a review from a team as a code owner November 7, 2023 23:33
.where(
new Brackets((qb) => {
qb.where("project.cloneUrl LIKE :searchTerm", { searchTerm: `%${searchTerm}%` }).orWhere(
"project.name LIKE :searchTerm",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any potential performance implications here on some existing UI?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does not seem we have an index of project name but on clone URL? Do we need to add one? cc @geropl

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case I don't think an index would help since it has a leading wildcard in the search. It would be helpful for sorting by name though, which we would like to have on the new list UI.

Copy link
Member

@akosyakov akosyakov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good

not sure about perf implications of the search by name. it seems we use it on admin UI.

Copy link
Member

@filiptronicek filiptronicek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Left a few non-blocking comments


async listConfigurations(req: ListConfigurationsRequest, context: HandlerContext) {
if (!req.organizationId) {
throw new ApplicationError(ErrorCodes.BAD_REQUEST, "organizationId is required");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@selfcontained what do you think about throwing with the argument names as specified in protobuf instead of their JS mutations?

As an example, we could have organization_id here instead, which corresponds to what its name is in GetConfigurationRequest.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call. It would be nice to have some level of abstraction around validation here that also handled that detail for us. I'll adjust these to use the protobuf field names though.

}

message PrebuildSettings {
optional bool enabled = 1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@selfcontained
Copy link
Contributor Author

/unhold

@roboquat roboquat merged commit df7929c into main Nov 8, 2023
16 checks passed
@roboquat roboquat deleted the brad/config-service branch November 8, 2023 20:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants