Repository navigation
feat(sdk): create a service built from a repository, with the Dockerfile that builds it - #12
Merged
Merged
Conversation
…ile that builds it createService took an upload source only, so a second service of a project (a dashboard next to its API) could not be created from the repository the project builds. It now takes a repository source too, with an optional dockerfilePath, and setServiceDockerfile names or clears that Dockerfile on an existing service. The service settings read returns the source with its dockerfilePath. NewUploadService stays exported; NewService is the body createService takes. Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
createServicetook an upload source only. A second service of a project, such as the dashboard of a DMS next to its API, could not be created from the repository the project already builds; it had to be uploaded by hand.The server accepts a repository source at creation, and AntelopeJS/cloud#647 adds the Dockerfile a repository service builds with (
dockerfilePath). This brings both to the public contract.What
createServicetakesNewService: an upload source as before, or{ type: "repository", repository, branch?, dockerfilePath? }.NewUploadServicestays exported, andNewRepositoryServiceis added.setServiceDockerfile(serviceId, path | null):PUT /api/cloud/services/{serviceId}/source-dockerfile. Null goes back to the rootDockerfileor a recipe.readServiceSettingsreturnssource(type,repository,dockerfilePath).sdk/openapi/services.yaml; the root spec gets smaller.Order
The setter and
dockerfilePathneed AntelopeJS/cloud#647 on the API they are called against. Merging this publishes nothing; the release that carries it should follow the release of #647. Until then the setter answers 404 and adockerfilePathat creation is ignored by the server.Tests
sdk/test/services.test.ts: a repository service is created with its repository and Dockerfile and answers its id; an upload service is created as before; the Dockerfile is put at the encoded service path, null included, and an empty answer is accepted; the two refusals come back asCloudApiErrorwith their code. 50 tests pass; the CLI type-checks against the new body.