Make NoArtifactError.Error() nil-safe

[Copilot]

NoArtifactError.Error() would panic on a nil err field, making zero-value construction (&NoArtifactError{}) unsafe — a pattern used throughout controller tests.

Changes

• pkg/deploymentrecord/client.go: Guard against both a nil receiver and a nil wrapped error in Error(), returning "no artifact found" in either case

func (n *NoArtifactError) Error() string {
    if n == nil || n.err == nil {
        return "no artifact found"
    }
    return fmt.Sprintf("no artifact found: %s", n.err.Error())
}

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[Copilot]

Pull request overview

This PR makes deploymentrecord.NoArtifactError.Error() safe to call when the receiver is nil or when the wrapped err field is nil, preventing panics from zero-value usage patterns (notably in controller tests).

Changes:

• Add nil checks in (*NoArtifactError).Error() to avoid panics when n or n.err is nil.
• Return a consistent fallback message ("no artifact found") for nil-safe cases.

---

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

[Copilot]

Error() is now nil-receiver safe, but Unwrap() still dereferences n unconditionally. If a nil *NoArtifactError is ever stored in an error interface, errors.Unwrap/Is can call Unwrap() and panic. Consider making Unwrap() return nil when the receiver is nil (and/or when n.err is nil) to keep the type fully nil-safe.

[Copilot]

This change adds a new behavior path (n == nil or n.err == nil) but there isn't a unit test asserting that (&NoArtifactError{}).Error() returns the expected message and does not panic. Adding a small regression test would prevent future reintroductions of the nil-deref.