fix(bitbucket): send the archive credential as a header - #130
Merged
Conversation
Bitbucket's archive host takes no credential from the url. A token offered as basic userinfo is answered with a redirect to a login page, so the fetch lands empty and the deployment waits on a build that never starts. The same host accepts the credential as a header, so the url is handed over plain and the header travels beside it. Its git endpoint still takes the credential in the url, which is where cloning leaves it. Replaces the capability added a commit ago: what a caller needs is the headers to send, not whether the url stands alone.
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.
Follows #129, which added the wrong abstraction. A Bitbucket deployment still never builds.
Cause
getRepositoryPresignedUrl()puts the token in the url as basic userinfo. Bitbucket's archive host takes no credential that way — it answers a redirect to a login page, the fetch lands empty, and the deployment waits on a build that never starts. Nothing errors.Measured against production with the real stored token:
x-token-auth:<oauth>@bitbucket.org/…/get/main.tar.gz?access_token=<oauth>Authorization: Bearer <oauth>Authorization: Basic <email:token>Only a header authenticates that host, and it works for both credential shapes the adapter handles.
Change
The url is handed over plain and
getRepositoryPresignedUrlHeaders()says what to send beside it.authorizationHeader()already picks Bearer or Basic per credential, so both are covered.authenticatedBitbucketUrl()stays forgenerateCloneCommand()— the git endpoint does accept a credential in the url.This replaces
supportsAuthenticatedArchiveUrl()from #129: what a caller needs is the headers to send, not whether the url stands alone. Routing around the archive fetch doesn't work — the builds worker clones only to push a template commit, then hands off through the same url.Follow-up
Appwrite passes these headers into the source
DownloadArtifact, which already accepts them.