Travis CI Retry Boundary with Deployment Writes: Preventing Duplicate Side Effects

Enforcing Idempotency at the Integration Boundary

Because Travis CI re-executes the entire job script during a retry, any state-altering operation—such as a database insert or an API call—will be repeated. Since the CI platform does not provide a built-in mechanism to suppress these duplicate writes, idempotency must be enforced by the downstream service.

The Idempotency Key Strategy

The safest approach is to generate a unique idempotency key within the Travis CI job and forward it to the deployment target. The downstream service should use this key to ensure that a specific build instance triggers a state change exactly once.

To create a stable identifier that persists across retries of the same build, combine the following environment variables:

• TRAVIS_COMMIT: The commit SHA.
• TRAVIS_BUILD_NUMBER: The unique identifier for the build instance.

Using only the commit SHA is insufficient, as it would block legitimate redeployments of the same commit. Combining it with the build number ensures that retries are deduplicated, but new build triggers for the same commit are still processed.

Safe Use of TRAVIS_RETRY_NUMBER

TRAVIS_RETRY_NUMBER can be used as a conditional gate to transform or skip operations, but it should not be the sole mechanism for preventing duplicates. If a previous attempt failed after the write occurred but before the job reported success, relying on the retry count alone will lead to inconsistent state.

Recommended Pattern:

1. Construct the key: ${TRAVIS_COMMIT}_${TRAVIS_BUILD_NUMBER}.
2. The build script sends this key to the downstream API.
3. The API checks if the key has already been processed successfully.
4. If processed, the API returns a cached success response without re-executing the write.

Coordinating Concurrent Retries and Webhooks

When concurrent retry attempts or out-of-order webhooks occur, the downstream service should implement a "last-write-wins" strategy or a distributed lock. Webhook consumers must validate the build sequence number to ensure that a delayed notification from an earlier retry does not overwrite the state established by a later, successful attempt.

Verification and Assumptions

This approach assumes the downstream service has the capacity to store and query idempotency keys. To verify this implementation:

• Confirm that TRAVIS_BUILD_NUMBER and TRAVIS_COMMIT are present in your job environment.
• Manually trigger a duplicate request to the deployment API using the same key and verify that no duplicate resource is created.

Note: Behavior regarding retry timeouts and resource quotas may vary by Travis CI tier; verify these limits within your specific organizational settings.