Best practices for handling reruns in gated PR workflows when reruns reuse the same run identifier

[francisco-mindbody]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Actions Runner

Discussion Details

We are working with gated pull request workflows and occasionally need to re-run a workflow after a failure.

On re-runs, GitHub preserves the same run_id and only increments the run_attempt. This is expected behavior, but it creates challenges when workflows create or validate external resources or artifacts during execution.

We’d like guidance on recommended patterns to ensure gated PR workflows can successfully complete when a re-run is required.

Questions

What is the recommended way to handle uniqueness when workflows are re-run?

Should run_attempt always be included when naming or validating resources?

Are there best practices for gated workflows that need to create or reconcile external state?

Are there common patterns GitHub recommends to make workflows re-run safe and idempotent?

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[CodeWIthAbdullah-007]

When handling reruns in GitHub Actions, it’s important to design workflows to be idempotent and capable of safely handling retries, since GitHub keeps the same run_id and increments run_attempt on reruns. Here are best practices for gated PR workflows:

Use run_attempt for uniqueness

When creating external resources (e.g., test environments, temporary databases, artifact names), include run_attempt along with run_id to generate unique identifiers.

Example: ${{ github.run_id }}-${{ github.run_attempt }}-artifact ensures that each rerun doesn’t clash with previous resources.

Design for idempotency

If a resource might already exist from a previous attempt, workflows should check for it and either reuse or safely replace it.

For external state, consider cleanup steps at the beginning or end of a workflow to remove leftover resources from previous attempts.

Use conditional creation / validation

Before creating a resource, validate whether it already exists or meets the desired state.

This ensures that reruns won’t fail due to conflicts or duplicates.

Separate ephemeral vs persistent resources

Keep ephemeral test artifacts isolated per run/attempt.

Persistent resources (like shared environments) should support concurrent access or reconciliation to avoid inconsistent state across reruns.

Logging and traceability

Include run_id and run_attempt in logs and artifact names for traceability.

This helps diagnose failures in gated PR workflows and ensures reruns can be correlated to previous attempts.

Summary:

Always include run_attempt when naming or validating external resources.

Make workflows idempotent and safe for reruns.

Validate existing resources before creating new ones.

Separate ephemeral and persistent resources to avoid conflicts.

These patterns ensure gated PR workflows remain reliable even when reruns are required.