Avoid Quay authentication failures for fork PRs in build-and-push-image

[Namanbhatt-01]

Problem

Fork PRs can currently reach the build-and-push-image workflow and fail at the Quay authentication step because repository registry credentials are not available in the fork context.

The observed failure is:

Username and password required

This was seen in:

• test(utils): attribute missing /proc prefixes to tracer or normalization layer #886 — build-and-push-image fails during Quay login
• fix(networkstream): key stream entities by container ID outside Kubernetes #887 — the same Quay authentication failure

The failure appears to be independent of the contributor's code changes. In #887, the Quay failure was also identified as a registry-credentials issue for a fork-sourced workflow run, and the PR was considered okay to merge despite the red check.

Why this is a problem

For external contributors, a red CI check caused by unavailable registry credentials is misleading. It makes it harder to tell whether the PR itself is valid and can discourage external contributions.

The registry publishing step also has a different purpose from normal PR validation: PR CI should primarily validate the submitted code, while publishing an image requires trusted registry credentials.

Expected behavior

Fork PRs should continue to receive the normal build/test/lint validation without requiring Quay credentials. The registry-dependent publishing step should only run when the workflow has the required credentials/permissions.

Two possible approaches are:

1. Build the image but do not push it for fork PRs.

   • Keeps Docker image build validation for contributors.
   • Avoids the Quay login/push step when credentials are unavailable.

2. Separate image publishing from normal PR validation.

   • PR workflows validate the code/image build without publishing.
   • A trusted workflow (for example, on the main/release path) handles Quay authentication and publishing.

Option 1 may be the smallest change, while option 2 may provide a cleaner long-term separation between PR validation and artifact publishing. The existing workflow dependencies can determine which approach fits best.

Related PRs

• test(utils): attribute missing /proc prefixes to tracer or normalization layer #886
• fix(networkstream): key stream entities by container ID outside Kubernetes #887

Goal

Remove the misleading registry-credential failure from fork PR validation while preserving useful CI coverage and keeping Quay credentials restricted to trusted workflow contexts.

[Namanbhatt-01]

@matthyx thanks for confirming in Slack that this direction would help external contributions.
I opened #896 based on the failures seen in #886 and #887.
I see two possible implementation directions:

1. Build but don't push for fork PRs — keeps Docker image build validation while avoiding the Quay credential-dependent step.
2. Separate image publishing from normal PR validation — keeps PR CI focused on validation and limits Quay publishing to trusted workflows.

My initial preference is B if the image build is useful as part of PR validation, but C may be cleaner architecturally if publishing is not needed by any PR checks.
Could you advise which direction better fits the current node-agent workflow/CI design? I can then investigate the workflow and work on the implementation.