fix: cloud runs resolve the pipeline by repo identity#139
Merged
Conversation
hm run derives owner/repo from the git remote and submits via submit_repo_build (POST /organizations/:org/builds), which resolves the pipeline by (repo_name, source_slug). Watch/cancel use the global slug the server returns on the build.
markovejnovic
force-pushed
the
fix/cloud-pipeline-resolution
branch
from
ebb91a5 to
a85a867
Compare
repo+source build submission is now available from crates.io.
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
1 participant
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
hm run --backend cloud404'd withpipeline_not_found: the CLI sent the bare DSL slug (ci), but the org's pipeline is stored under the namespaced global slug (harmont-dev-harmont-cli-ci, from GitHub discovery). The CLI never knew the global slug.This derives
owner/repofrom the worktree's git remote and submits via the new SDKsubmit_repo_build→POST /api/v0/organizations/:org/builds, which resolves the pipeline by(repo_name, source_slug). Watch/cancel/log endpoints are still addressed by the global slug — so the CLI now takes that slug from thepipeline_slugthe server returns on the created build.A remoteless worktree (no
origin) fails cloud runs with a clear doctrine error instead of a confusing 404.Changes
parse_repo_name+git_remote_repo_name(hm/src/commands/run/mod.rs) + unit tests covering https/ssh/scp/unparseable.SourceMeta.repo_name: Option<String>; populated from the git remote.CloudBackendsubmitsNewRepoBuildand watches/cancels bybuild.pipeline_slug.No
Cargo.tomlchange needed: the existingharmont-cloud = "0.1"requirement already covers the new0.1.3(the SDK change is additive → a patch bump).The Rust SDK is consumed from crates.io, but
0.1.3(withsubmit_repo_build+Build.pipeline_slug) is not published yet — its source is in the companion simci PR #77. To finish:harmont-cloud-raw@0.1.3thenharmont-cloud@0.1.3to crates.io.cargo update -p harmont-cloud -p harmont-cloud-rawto pull 0.1.3 intoCargo.lock, then mark ready. CI goes green.Verification
Locally verified green against the unpublished SDK via a temporary
[patch.crates-io]path override (removed before commit):cargo build,cargo clippy --all-targets -- -D warnings, andcargo test(191 passed) all clean.🤖 Generated with Claude Code