Repository navigation
CLI: reject an already-published version before uploading anything - #18
Merged
Merged
Conversation
publish now fetches the project's releases first and stops if the version is already published, so a repeat (e.g. pushing 0.3.1 twice) fails in seconds instead of after a full build upload, with the existing message telling the developer to bump "version" in vapour.toml or pass --version. The server-side 409 version_exists handling stays as the fallback.
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.
What
vapour publishnow checks the project's published releases (GET /projects/:id) before uploading anything. If the version is already published — e.g.0.3.1was pushed andvapour.tomlstill saysversion = '0.3.1'— it fails immediately with:Why
The only enforcement was the server's 409
version_exists, which the CLI discovers after the whole build zip has been uploaded. For a large build that is minutes of wasted upload before the developer is told to change the config.Changes
internal/api:Client.GetProject(owner view of a project) andGame.Releases/Release.cmd/publish.go:checkVersionFreeruns right afterensureProject, before the store page push and the build upload. The 409 handling stays as the fallback (two publishes racing, or an older server).cmd/cmd_test.go: fake API servesGET /projects/g1with the published releases; the flow test asserts the blocked repeat never reaches/projects/:id/publish(server sees only0.2.0and0.3.0).Testing
go build ./...andgo test ./...pass (run in a clean copy of the tree; note the untracked WIP filescmd/controller.go,cmd/template.go,internal/devserveretc. in the working dir do not compile againstinternal/projectyet — unrelated to this change).