Skip to content

[fix] support codeload github archive urls for artifactory (#710)#712

Open
edenfunf wants to merge 1 commit intomicrosoft:mainfrom
edenfunf:fix/codeload-artifactory-archive-url
Open

[fix] support codeload github archive urls for artifactory (#710)#712
edenfunf wants to merge 1 commit intomicrosoft:mainfrom
edenfunf:fix/codeload-artifactory-archive-url

Conversation

@edenfunf
Copy link
Copy Markdown
Contributor

What

Add support for codeload.github.com-style archive URLs in Artifactory archive URL generation.

Why

Issue #710 reports that organizations using JFrog Artifactory as a proxy for private GitHub repositories need to configure the Artifactory upstream to codeload.github.com instead of github.com. This is because Artifactory cannot follow the cross-host redirect that GitHub issues for private repo archives (which carries a short-lived token to codeload.github.com that Artifactory drops). When the upstream is codeload.github.com, the required archive path pattern is:

/{owner}/{repo}/zip/refs/heads/{ref}      # no .zip extension
/{owner}/{repo}/zip/refs/tags/{ref}

APM currently only generates github.com-style paths (/archive/refs/heads/{ref}.zip), so downloads via a codeload-upstreamed Artifactory always fail.

How

build_artifactory_archive_url() already returns a tuple of URLs to try in order — the downloader iterates through them and stops on the first 200. I added the two codeload-style paths at the end of the tuple, preserving existing GitHub and GitLab behavior entirely.

Changed files:

  • src/apm_cli/utils/github_host.py — adds codeload paths to the returned tuple and updates the docstring
  • tests/unit/test_artifactory_support.py — four new regression tests; one existing assertion updated to reflect the new URL count (3 → 5)

Test

  • verified existing github.com archive URL behavior remains unchanged (test_github_archive_urls_unchanged)
  • verified GitLab behavior remains unchanged (test_gitlab_archive_urls_unchanged)
  • added regression test for codeload heads ref: test_codeload_upstream_heads_ref
  • added regression test for codeload tags fallback: test_codeload_upstream_tags_ref
  • full test suite: 107 passed, 0 failed
tests/unit/test_artifactory_support.py::TestBuildArtifactoryArchiveUrl::test_default_ref PASSED
tests/unit/test_artifactory_support.py::TestBuildArtifactoryArchiveUrl::test_custom_ref PASSED
tests/unit/test_artifactory_support.py::TestBuildArtifactoryArchiveUrl::test_real_artifactory_host PASSED
tests/unit/test_artifactory_support.py::TestBuildArtifactoryArchiveUrl::test_codeload_upstream_heads_ref PASSED
tests/unit/test_artifactory_support.py::TestBuildArtifactoryArchiveUrl::test_codeload_upstream_tags_ref PASSED
tests/unit/test_artifactory_support.py::TestBuildArtifactoryArchiveUrl::test_github_archive_urls_unchanged PASSED
tests/unit/test_artifactory_support.py::TestBuildArtifactoryArchiveUrl::test_gitlab_archive_urls_unchanged PASSED
...
107 passed in 0.63s

When an Artifactory instance's upstream is configured as
codeload.github.com (the workaround for private repos where github.com
issues cross-host redirects that Artifactory cannot follow),
build_artifactory_archive_url() now also generates codeload-style paths:

  /{owner}/{repo}/zip/refs/heads/{ref}
  /{owner}/{repo}/zip/refs/tags/{ref}

These are appended to the existing tuple so the caller's try-in-order
loop probes both styles; existing github.com and GitLab behavior is
unchanged.

Fixes microsoft#710
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant