Allow strict mode compilation when action SHA resolution fails

[Copilot]

Strict mode was blocking compilation when unable to resolve action SHAs. This is overly restrictive - resolution can fail due to rate limits, network issues, or private repositories.

Changes

• pkg/workflow/action_pins.go: Removed strict mode error path for unresolved action pins. Now emits warning and continues compilation in both modes.

• pkg/workflow/action_pins_logging_test.go: Updated test expectations from error to warning.

Behavior

Before:

// Strict mode
if data.StrictMode {
    errMsg := fmt.Sprintf("Unable to pin action %s@%s: resolution failed", repo, version)
    return "", fmt.Errorf("%s", errMsg)  // Compilation fails
}

After:

// Both modes emit warning and continue
warningMsg := fmt.Sprintf("Unable to pin action %s@%s: resolution failed", repo, version)
fmt.Fprintln(os.Stderr, console.FormatWarningMessage(warningMsg))
return "", nil  // Compilation succeeds

Strict mode now treats action pin resolution failures as non-fatal, allowing workflows to compile and run with best-effort SHA pinning.

Original prompt

Failing to resolve the long sha for action pins should NOT fail strict mode. It should be a warning but not a failure. It is not always possible to resolve the pins.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[github-actions]

🔍 PR Triage Results

Category: bug | Risk: medium | Priority: 43/100

Scores Breakdown

• Impact: 30/50 - Bug fix in action pin resolution logic affecting strict mode behavior in workflow compilation
• Urgency: 5/30 - WIP status, very new (< 1 hour old), affects compilation behavior but not critical
• Quality: 8/20 - CI pending, WIP status, includes test updates but implementation incomplete

📋 Recommended Action: defer

Explanation: This WIP PR addresses action pin resolution failures in strict mode by converting errors to warnings. The approach is sensible but needs completion and CI validation before review.

Next Steps:

1. Complete implementation and remove [WIP] tag
2. Verify test coverage for both strict and non-strict modes
3. Wait for CI validation
4. Request review

---

Triaged by PR Triage Agent on 2026-02-12

AI generated by PR Triage Agent

[Copilot]

Pull request overview

This PR adjusts workflow compilation behavior so that failures to resolve/pin GitHub Actions SHAs no longer block compilation in strict mode, reflecting that pin resolution can legitimately fail (rate limits, network, private repos).

Changes:

• Update GetActionPinWithData to emit warnings and return an empty pin instead of erroring when no pin can be resolved (including strict mode).
• Update strict-mode logging tests to assert warning behavior rather than expecting an error.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
pkg/workflow/action_pins.go	Removes strict-mode fatal error on unresolved pins; emits warnings and continues compilation.
pkg/workflow/action_pins_logging_test.go	Updates strict-mode test to validate warnings/no-error behavior.

Comments suppressed due to low confidence (2)

pkg/workflow/action_pins.go:163

• GetActionPinWithData dereferences data (e.g., data.StrictMode, data.ActionResolver, data.ActionPinWarnings) without a nil check. Since the function accepts *WorkflowData, a nil caller would panic. Add an early guard (e.g., treat nil as default non-strict/no-resolver) or change the contract to explicitly reject nil with a returned error.

func GetActionPinWithData(actionRepo, version string, data *WorkflowData) (string, error) {
	actionPinsLog.Printf("Resolving action pin: repo=%s, version=%s, strict_mode=%t", actionRepo, version, data.StrictMode)

pkg/workflow/action_pins_logging_test.go:192

• In the expectSuccess branch, the test asserts result != "" but does not assert that no warning was emitted. Add an assertion that stderrOutput does not contain a warning marker/message (e.g., "Unable to pin action" or "⚠") to ensure successful strict-mode resolution stays quiet.

			if tt.expectSuccess {
				// Should not emit warning and return non-empty result
				if err != nil {
					t.Errorf("Unexpected error: %v", err)
				}
				if result == "" {
					t.Errorf("Expected non-empty result")
				}
			}

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Grammar: "In both strict and non-strict mode" should be "In both strict and non-strict modes".

Suggested change

	// In both strict and non-strict mode, emit warning and return empty string (unless it's already a SHA)
	// In both strict and non-strict modes, emit warning and return empty string (unless it's already a SHA)