Skip to content

RTECO-2003: fix the failing Chocolatey tests - #3720

Open
bhanurp wants to merge 7 commits into
masterfrom
RTECO-2003-choco-test-fixes
Open

bhanurp wants to merge 7 commits into
masterfrom
RTECO-2003-choco-test-fixes

Conversation

@bhanurp

@bhanurp bhanurp commented Sep 25, 2026

Copy link
Copy Markdown
Contributor

Why

Twelve Chocolatey tests have been failing on master since #3708 merged. They are not a regression from any open PR — the same 12 failures appear on the master push run and on unrelated PR runs. They only surfaced now because build-gate.yml runs from the base branch on pull_request_target, so the choco: job first went live the moment #3708 landed.

Three distinct causes, all addressed here.

1. Nine tests — non-HTTPS Artifactory source rejected

jfrog-cli-artifactory enforced HTTPS for choco and only for choco; jf setup nuget, jf setup dotnet, jf nuget and jf setup psresource all resolve the same source with no scheme check. CI runs against http://localhost:8081, so choco was rejected outright with refusing to use a non-HTTPS Artifactory source.

Fixed in jfrog/jfrog-cli-artifactory#569, pinned here. That PR also fixes the flag-only pass-through bug behind TestChocoPassThroughWithoutServerConfigured: getCommandName returns "" when every argument starts with -, so jf choco --version handed choco a leading empty argument, which made it print its output and then exit 1 (choco failed: exit status 1, with the tell-tale double space).

Affected: TestChocoPushBuildInfoAndProperties, TestChocoPushToVirtualRepoConvention, TestChocoBuildFlagsValidation, TestChocoBuildInfoFromEnvVars, TestChocoModuleOverride, TestSetupChocoConfiguresSource, TestChocoInstallCollectsDependencies, TestChocoPushWithoutPositionalPath, TestChocoInstallRecordsVersionFromInstalledPackage.

2. TestChocoCommandPropertyRedactsApiKey — crashed rather than failed

chocoPushApiKey read serverDetails.User directly, but authenticate() (artifactory_test.go:112-117) sets User only for the user/password form and leaves it empty whenever an access token was supplied — which is how CI runs. Chocolatey rejected the resulting ":<token>" as invalid credentials, fell back to an interactive credential prompt with no console attached, and died with exit status 0xe0434352 (a .NET unhandled exception).

Derive the user from the token via the existing credentialsForTestServer helper — the same auth.ExtractUsernameFromAccessToken path the product code uses in GetSourceDetails — and fail with a readable message rather than crashing if it cannot be derived.

3. Chocolatey OS gate (linux) — should never have run

The job failed on dial tcp [::1]:8081: connect: connection refused while fetching /artifactory/api/repositories/cli-nuget-remote-…: suite-level repository setup runs before -run narrows to the two gate tests, so it reached for an Artifactory the job deliberately does not provision.

Chocolatey is a Windows-only package manager, so the job is removed rather than patched. The non-Windows refusal stays covered by TestChocoCommandNonWindowsFailsClearly in jfrog-cli-artifactory, which does run on Linux. --test.choco now appears only on the Windows job.

Verification

  • go build ./... — clean
  • go vet . — clean (compiles the test package)
  • gofmt -l — clean
  • gosec ./... — 26 findings, all pre-existing, none in choco_test.go
  • golangci-lint run . — 0 issues

Before merge

go.mod pins jfrog-cli-artifactory to ae6e6f3 on the #569 branch. Once #569 merges, re-pin to main.

🤖 Generated with Claude Code

Twelve Chocolatey tests have been failing on master since #3708 merged and the
suite first ran in CI. This addresses the three causes.

Nine of them failed because jfrog-cli-artifactory refused a non-HTTPS Artifactory
source for choco only, so CI's http://localhost:8081 was rejected. Fixed in
jfrog-cli-artifactory#569, which also fixes the flag-only pass-through bug behind
TestChocoPassThroughWithoutServerConfigured; pinned here.

TestChocoCommandPropertyRedactsApiKey crashed rather than failed. chocoPushApiKey
read serverDetails.User directly, but authenticate() sets User only for the
user/password form and leaves it empty whenever an access token was supplied -
which is how CI runs. Chocolatey rejected the resulting ':<token>' as invalid
credentials, fell back to an interactive prompt with no console attached, and died
with 0xe0434352. Derive the user from the token via the existing
credentialsForTestServer helper, and fail with a readable message if it cannot be.

The Chocolatey OS gate job ran on ubuntu-24.04 and failed on 'dial tcp
[::1]:8081: connect: connection refused': suite-level repository setup runs before
-run narrows to the two gate tests, so it reached for an Artifactory the job
deliberately does not provision. Chocolatey is Windows-only, so the job is removed
rather than patched. The non-Windows refusal stays covered by
TestChocoCommandNonWindowsFailsClearly in jfrog-cli-artifactory, which runs on Linux.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…dentials fix

Picks up the fix that stores read credentials on the Chocolatey source, without
which 'jf choco install' fails with HTTP 401 against an authenticated repository.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bhanurp and others added 2 commits September 25, 2026 22:33
The only remaining --test.choco job is windows-2022, and TestChocoNonWindowsGate
skipped itself on Windows, so its body could no longer run anywhere. The gate's
rejection message is asserted by TestChocoCommandNonWindowsFailsClearly in
jfrog-cli-artifactory, which stubs the platform check and therefore runs on Linux
in that repo's normal suite. Fold the single-caller initChocoTestAnyPlatform
helper into TestChocoHelpWorksOnAllPlatforms.

Re-pin jfrog-cli-artifactory to pick up the Chocolatey setup cleanup.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…l fix

Picks up the username requirement and the source read credentials, so
'choco install' authenticates against an Artifactory NuGet feed instead of
returning HTTP 401.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
TestChocoInstallCollectsDependencies asserted dependency.Repository on the
build info read back from Artifactory after "jf rt bp". A dependency's
Repository is a client-side field that Artifactory does not store - the same
way entities.Artifact.OriginalDeploymentRepo is documented as internal-only -
so the assertion could only ever have tested Artifactory's serialization, and
it came back empty. The assertion had never executed before now: every earlier
run of this test failed on the HTTP 401 that the credential fix resolved.

Assert --repo-resolve where the value actually lives instead, by reading the
partial build-info files off disk before the publish. The coverage is kept and
now exercises the wiring it was written for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bhanurp and others added 2 commits September 25, 2026 23:39
The previous commit read the collected dependencies with
ReadPartialBuildInfoFiles, which found nothing: 'jf choco' persists a whole
build-info file through Build.SaveBuildInfo rather than per-module partials, so
the partials directory is empty.

Read it with GetGeneratedBuildsInfo instead, the same call the conan tests use
for locally saved build info, and walk the modules for their dependencies.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Picks up 7443887, which annotates the fake reference token in the choco setup
tests so the Go-Sec job passes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

👍 Frogbot scanned this pull request and did not find any new security issues.


@fluxxBot
fluxxBot self-requested a review September 25, 2026 18:17

This branch was successfully deployed

1 active deployment
build-gate — 11b62531 Deployed Sep 25, 2026 by bhanurp via Approval gate #1243
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.

2 participants