feat: base quickstart on remote existing target #999
Conversation
adaam2
force-pushed
the
feat/quickstart-existing-spec
branch
from
2276055
to
303e234
Compare
adaam2
force-pushed
the
feat/quickstart-existing-spec
branch
from
303e234
to
4a0e465
Compare
| return "", fmt.Errorf("could not generate registry uri: missing organization or workspace slug") | ||
| } | ||
|
|
||
| return fmt.Sprintf("registry.speakeasyapi.dev/%s/%s/%s@%s", orgSlug, workspaceSlug, sourceNamespace, sourceRevisionDigest), nil |
There was a problem hiding this comment.
We have a proper parser for this - you should reuse that, this format could change over time
There was a problem hiding this comment.
speakeasy-api/[email protected]/workflow/source.go
ParseRegistryLocation
|
|
||
| // GetRecentWorkspaceGenerations returns the most recent generations of targets in a workspace | ||
| // This is based on the CLi event stream, which is updated on every CLI interaction. | ||
| func GetRecentWorkspaceGenerations(ctx context.Context) ([]RecentGeneration, error) { |
There was a problem hiding this comment.
I think we should look to make this smart. We should prioritize targets that are actually connected to Github or are connected to publishing. We may want to consider only including these targets
Once someone is already onboarded we probably don't want people basing new SDKs off of random local generations on someone's machine, I think that will lead to problems because these specs may never be updated again.
| } | ||
|
|
||
| // The event stream is limited to the most recent 250 events | ||
| res, err := speakeasyClient.Events.SearchWorkspaceEvents(ctx, operations.SearchWorkspaceEventsRequest{ |
There was a problem hiding this comment.
You could consider getWorkspaceTargets here instead. Aggregate on unique targets rather than just by events. All 250 events could be more the same target and that target may not be useful.
| } else if useRemoteSource && selectedRegistryUri != "" { | ||
| // The workflow file will be updated with a registry based input like: | ||
| // inputs: | ||
| // - location: registry.speakeasyapi.dev/speakeasy-self/speakeasy-self/petstore-oas@latest |
There was a problem hiding this comment.
Using latest does have some risk given it's written to locally and in CI. All of a sudden a customer could have published SDKs that are being generated based off of local executions of another SDK without them knowing.
This PR adds the ability to bootstrap a new target using a pre-existing specification hosted on Speakeasy's registry. The CLI will now show the most recent 5 targets that have been interacted with (based on the CLI event stream).
If there are any recent target candidates in the workspace, then the user will be presented with the option to choose from an existing SDK or create from scratch at the beginning of Quickstart. If there are no previous generations in a workspace, then the existing "new user" flow will be shown where the user can enter a filepath to a spec:
Then selecting from the list of recent SDKs:
(n.b the look and feel of the select list in the 2nd screenshot will change / look much better once the corresponding charmbracelet/huh#424 pr has been merged)
The end result is that a new workflow file is created that references the existing Registry URI for the spec from the previous target
Next steps
gen.yaml