RTECO-2247: Add jf Install-/Save-/Update-/Publish-PSResource commands

[bhanurp]

Summary

Part of RTECO-2247 — registers four top-level commands wrapping PowerShell's PSResourceGet module: jf Install-PSResource, jf Save-PSResource, jf Update-PSResource, jf Publish-PSResource. Deliberately four separate commands (matching native PowerShell cmdlet names) rather than one jf psresource <verb> wrapper — unlike jf choco, which uses a single-command, first-positional-argument dispatch.

Dependencies — all three merged, and go.mod now pins each one at its merge commit:

• build-info-go: RTECO-2247: PSResource (PowerShell PSResourceGet) FlexPack collectors build-info-go#430 → v1.13.1-0.20260925090031-f9d40441f262
• jfrog-cli-core: RTECO-2247: Add PSResource project type jfrog-cli-core#1620 → v2.60.1-0.20260925084932-b47892ded3a0
• jfrog-cli-artifactory: RTECO-2247 - PSResource (PowerShell PSResourceGet) setup + FlexPack command jfrog-cli-artifactory#563 → v0.8.1-0.20260925102921-90d18d083a8b

Note on go.mod: the three release-blocking replace directives are gone — each dependency is pinned at the merge commit of its sibling PR, so the required No-Replace check passes. Each of those commits is the current head of its default branch and already contains the Chocolatey work, so nothing is held back. The transitive golang.org/x/* bumps (including crypto v0.57.0) come with those pins.

What's here

• buildtools/cli.go — the four cli.Command entries, built from a shared table (psResourceCommandEntries) rather than four hand-duplicated literals, all backed by one psResourceCmd(cmdletName) helper.
• docs/buildtools/psresource/help.go — per-cmdlet help text, rendered from one shared template parameterized by a small cmdletMeta struct (the four cmdlets' help is ~90% identical prose).
• utils/cliutils/commandsflags.go — the shared flag set (--build-name, --build-number, --module, --project, --repo, --repo-resolve, --server-id).
• Integration tests (psresource_test.go) — help text on every platform, CLI-level build-flag-pair validation, and (skipping gracefully without a local pwsh + PSResourceGet install) end-to-end dependency/artifact build-info collection for all four commands.
• CI workflow (psresourceTests.yml) — cross-platform (Linux/macOS/Windows), unlike jf choco's Windows-only requirement, since PSResourceGet via pwsh is cross-platform.

Notable bug fix included (found via an adversarial multi-agent code review after the initial implementation)

• Curation audit silently disabled: WrapCmdWithCurationPostFailureRun was called with each cmdlet's own PascalCase name ("Install-PSResource", etc.) as cmdName, but jfrog-cli-security's post-failure curation audit gates on a fixed, generic verb allowlist ({install, build, i, add, ci, get, mod}) shared across every package manager — none of our names was ever in it, so the audit was a silent no-op for all four commands. Install/Save/Update now pass the matching "install" verb; Publish (which uploads rather than resolves a package, so curation can't block it the way this audit checks for) runs directly without a curation cmdName that would never apply.

Test plan

• go test . -run PSResource -v -args -test.psresource=true and go test ./buildtools/... ./docs/buildtools/psresource/... — all pass (end-to-end tests skip gracefully on this machine, which has no pwsh installed).

• New regression tests for the curation-cmdName fix, GetAIDescription's per-cmdlet map lookup, and dispatch-reaching coverage for Save/Update/Publish (previously only Install-PSResource's real dispatch logic was ever exercised past the shared --help early-return).

• golangci-lint clean, gofmt clean.

• All tests passed. New tests added for the bug found during review.

• All static analysis checks passed.

• This pull request is on the master branch.

• I used gofmt for formatting the code before submitting the pull request.

• Full flow was locally tested (help text on every platform; end-to-end paths verified with pwsh unavailable, which is the graceful-skip path).

🤖 Generated with Claude Code

---

Ready for review: the sibling PRs have merged and the replace directives have been removed, so the required No-Replace check no longer blocks this branch. upstream/master has also been merged in, resolving the overlap with the Chocolatey PR (#3708) in buildtools/cli.go, docs/buildtools/setup/help.go, utils/tests/consts.go and utils/tests/utils.go by keeping both package managers.

[github-actions]

View full scan results in JFrog Platform

📗 Scan Summary

• Frogbot scanned for vulnerabilities and found 3 issues

Scan Category	Status	Security Issues
Software Composition Analysis	✅ Done	Not Found
Contextual Analysis	✅ Done	-
Static Application Security Testing (SAST)	✅ Done	3 Issues Found 3 Low
Secrets	✅ Done	Not Found
Services	✅ Done	Not Found
Infrastructure as Code (IaC)	✅ Done	Not Found

---

🐸 JFrog Frogbot

[github-actions]

NpmLocalRepositoryConfig

at utils/tests/consts.go (line 96)

🎯 Static Application Security Testing (SAST) Vulnerability

Severity	Finding
Low	Credentials for restricted resources included directly in source code

Full description

Vulnerability Details

Rule ID:	go-hardcoded-credentials

Overview

Hardcoded credentials are usernames, passwords, API keys, or other secrets
embedded directly in source code. This practice, identified by CWE-798, is
highly insecure because it makes it easy for anyone with access to the code to
discover and misuse the credentials. If the code is publicly released, shared,
or leaked, the credentials will be exposed to unauthorized parties.

Vulnerable example

In this example, the database username and password for the frog pond are
hardcoded directly in the source code as string literals. This is a major
security risk, as anyone who can read this file can steal the credentials and
gain unauthorized access to the database.

package main

import (
	"database/sql"
	"fmt"
	"log"

	_ "[github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)"
)

func main() {
	// VULNERABLE: Hardcoded database credentials for the frog pond.
	frogUser := "pond_admin"
	frogPassword := "LeapFlog123!"
	pondName := "lilypad_db"

	connStr := fmt.Sprintf("%s:%s@tcp(127.0.0.1:3306)/%s",
		frogUser, frogPassword, pondName)

	lilypadDB, err := sql.Open("mysql", connStr)
	if err != nil {
		log.Fatalf("Error opening database: %v", err)
	}
	defer lilypadDB.Close()

	err = lilypadDB.Ping()
	if err != nil {
		log.Fatalf("Error pinging database: %v", err)
	}
	fmt.Println("Successfully connected to the frog pond.")
}

Remediation

The remediated code retrieves the database credentials from environment
variables instead of hardcoding them. This is a much more secure approach, as
it separates the secrets from the source code. This allows credentials to be
managed securely by deployment systems and rotated without changing the code.

package main

import (
	"database/sql"
	"fmt"
	"log"
	"os"

	_ "[github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)"
)

func main() {
	// SECURE: Retrieve credentials from environment variables.
	frogUser := os.Getenv("FROG_DB_USER")
	frogPassword := os.Getenv("FROG_DB_PASS")
	pondName := os.Getenv("FROG_DB_NAME")

	if frogUser == "" || frogPassword == "" || pondName == "" {
		log.Fatal("DB credentials are not set in environment variables.")
	}

	connStr := fmt.Sprintf("%s:%s@tcp(127.0.0.1:3306)/%s",
		frogUser, frogPassword, pondName)

	lilypadDB, err := sql.Open("mysql", connStr)
	if err != nil {
		log.Fatalf("Error opening database: %v", err)
	}
	defer lilypadDB.Close()

	err = lilypadDB.Ping()
	if err != nil {
		log.Fatalf("Error pinging database: %v", err)
	}
	fmt.Println("Successfully connected to the frog pond.")
}

---

🐸 JFrog Frogbot

[github-actions]

NpmLocalScopedRespositoryConfig

at utils/tests/consts.go (line 97)

🎯 Static Application Security Testing (SAST) Vulnerability

Severity	Finding
Low	Credentials for restricted resources included directly in source code

Full description

Vulnerability Details

Rule ID:	go-hardcoded-credentials

Overview

Hardcoded credentials are usernames, passwords, API keys, or other secrets
embedded directly in source code. This practice, identified by CWE-798, is
highly insecure because it makes it easy for anyone with access to the code to
discover and misuse the credentials. If the code is publicly released, shared,
or leaked, the credentials will be exposed to unauthorized parties.

Vulnerable example

In this example, the database username and password for the frog pond are
hardcoded directly in the source code as string literals. This is a major
security risk, as anyone who can read this file can steal the credentials and
gain unauthorized access to the database.

package main

import (
	"database/sql"
	"fmt"
	"log"

	_ "[github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)"
)

func main() {
	// VULNERABLE: Hardcoded database credentials for the frog pond.
	frogUser := "pond_admin"
	frogPassword := "LeapFlog123!"
	pondName := "lilypad_db"

	connStr := fmt.Sprintf("%s:%s@tcp(127.0.0.1:3306)/%s",
		frogUser, frogPassword, pondName)

	lilypadDB, err := sql.Open("mysql", connStr)
	if err != nil {
		log.Fatalf("Error opening database: %v", err)
	}
	defer lilypadDB.Close()

	err = lilypadDB.Ping()
	if err != nil {
		log.Fatalf("Error pinging database: %v", err)
	}
	fmt.Println("Successfully connected to the frog pond.")
}

Remediation

The remediated code retrieves the database credentials from environment
variables instead of hardcoding them. This is a much more secure approach, as
it separates the secrets from the source code. This allows credentials to be
managed securely by deployment systems and rotated without changing the code.

package main

import (
	"database/sql"
	"fmt"
	"log"
	"os"

	_ "[github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)"
)

func main() {
	// SECURE: Retrieve credentials from environment variables.
	frogUser := os.Getenv("FROG_DB_USER")
	frogPassword := os.Getenv("FROG_DB_PASS")
	pondName := os.Getenv("FROG_DB_NAME")

	if frogUser == "" || frogPassword == "" || pondName == "" {
		log.Fatal("DB credentials are not set in environment variables.")
	}

	connStr := fmt.Sprintf("%s:%s@tcp(127.0.0.1:3306)/%s",
		frogUser, frogPassword, pondName)

	lilypadDB, err := sql.Open("mysql", connStr)
	if err != nil {
		log.Fatalf("Error opening database: %v", err)
	}
	defer lilypadDB.Close()

	err = lilypadDB.Ping()
	if err != nil {
		log.Fatalf("Error pinging database: %v", err)
	}
	fmt.Println("Successfully connected to the frog pond.")
}

---

🐸 JFrog Frogbot

[github-actions]

NpmRemoteRepositoryConfig

at utils/tests/consts.go (line 98)

🎯 Static Application Security Testing (SAST) Vulnerability

Severity	Finding
Low	Credentials for restricted resources included directly in source code

Full description

Vulnerability Details

Rule ID:	go-hardcoded-credentials

Overview

Hardcoded credentials are usernames, passwords, API keys, or other secrets
embedded directly in source code. This practice, identified by CWE-798, is
highly insecure because it makes it easy for anyone with access to the code to
discover and misuse the credentials. If the code is publicly released, shared,
or leaked, the credentials will be exposed to unauthorized parties.

Vulnerable example

In this example, the database username and password for the frog pond are
hardcoded directly in the source code as string literals. This is a major
security risk, as anyone who can read this file can steal the credentials and
gain unauthorized access to the database.

package main

import (
	"database/sql"
	"fmt"
	"log"

	_ "[github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)"
)

func main() {
	// VULNERABLE: Hardcoded database credentials for the frog pond.
	frogUser := "pond_admin"
	frogPassword := "LeapFlog123!"
	pondName := "lilypad_db"

	connStr := fmt.Sprintf("%s:%s@tcp(127.0.0.1:3306)/%s",
		frogUser, frogPassword, pondName)

	lilypadDB, err := sql.Open("mysql", connStr)
	if err != nil {
		log.Fatalf("Error opening database: %v", err)
	}
	defer lilypadDB.Close()

	err = lilypadDB.Ping()
	if err != nil {
		log.Fatalf("Error pinging database: %v", err)
	}
	fmt.Println("Successfully connected to the frog pond.")
}

Remediation

The remediated code retrieves the database credentials from environment
variables instead of hardcoding them. This is a much more secure approach, as
it separates the secrets from the source code. This allows credentials to be
managed securely by deployment systems and rotated without changing the code.

package main

import (
	"database/sql"
	"fmt"
	"log"
	"os"

	_ "[github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)"
)

func main() {
	// SECURE: Retrieve credentials from environment variables.
	frogUser := os.Getenv("FROG_DB_USER")
	frogPassword := os.Getenv("FROG_DB_PASS")
	pondName := os.Getenv("FROG_DB_NAME")

	if frogUser == "" || frogPassword == "" || pondName == "" {
		log.Fatal("DB credentials are not set in environment variables.")
	}

	connStr := fmt.Sprintf("%s:%s@tcp(127.0.0.1:3306)/%s",
		frogUser, frogPassword, pondName)

	lilypadDB, err := sql.Open("mysql", connStr)
	if err != nil {
		log.Fatalf("Error opening database: %v", err)
	}
	defer lilypadDB.Close()

	err = lilypadDB.Ping()
	if err != nil {
		log.Fatalf("Error pinging database: %v", err)
	}
	fmt.Println("Successfully connected to the frog pond.")
}

---

🐸 JFrog Frogbot