Handling errored changesets
Publishing a changeset can result in an error for different reasons.
Sometimes the problem can be fixed by automatically retrying to publish the changeset, but other errors require the user to take some action.
Errored changesets that are marked as Retrying are being automatically retried:
Changesets that are marked as Failed can be retried manually:
Types of errors
Examples of errors that can be fixed by automatically retrying:
- Connecting to the code host failed
- Code host responds with an error when trying to open a pull request
- Internal network errors
Examples of errors that requires manual retrying:
- No Batch Changes credentials have been setup for the affected code host
- The configured code host connection needs a different type of credentials (e.g. with SSH keys)
- A pull request for the specified branch already exists in another batch change
Automatic retrying of errored changesets
When Sourcegraph batch changes marks a changeset as Retrying it’s automatically going to retry publishing it for up to 60 times.
No user action is needed.
Manual retrying of errored changesets
Changesets that are marked as Failed won’t be retried automatically. That’s either because the number of automatic retries has been exhausted, or because retrying won’t fix the error without user intervention.
When a changeset failed publishing, the user can click Retry on the error message. No re-applying needed.
Additionally, in order to retry all Failed (or even Retrying) changesets manually, you can re-apply the batch spec.
Option 1: Preview and re-apply the batch spec in the UI by running
src batch preview -f YOUR_BATCH_SPEC.batch.yaml
and clicking on the printed URL to apply the uploaded batch spec.
Option 2: Re-apply directly by running the following:
src batch apply -f YOUR_BATCH_SPEC.batch.yaml
See “Creating a batch change” for more information on these commands.