High Availability
This page is about what you can do on your side so that builds keep working when a request to CloudRepo fails.
How CloudRepo hosts your data, where it runs and how it recovers from failures are described on CloudRepo’s security practices page, not here.
When a request fails
Section titled “When a request fails”Troubleshooting maps each status code to its usual cause. Two groups matter here:
401,403,404and409are CloudRepo’s answers to the request you sent: a refused credential, a token that cannot reach the repository, a path that holds nothing, a path that already holds a file. Sending the same request again gets the same answer until you change something.5xx, a timeout, or no answer at all are not about your credential or your request. Check status.cloudrepo.io, then try again, then contact support if it keeps failing.
Retry what is worth retrying
Section titled “Retry what is worth retrying”Let your tools try again on a failure that is not a refusal:
- curl retries a transient error when you pass
--retrywith a number. The default is no retries. - pip retries a connection it cannot establish:
--retriessets how many attempts, and the default is 5. - npm retries idempotent read requests on a network failure or a
5xx: thefetch-retriessetting, default 2, sets how many.
curl --netrc --fail --retry 3 --output hello-copy.txt \ https://your-org.mycloudrepo.io/repositories/your-repo/uploads/hello.txtRetry downloads freely. Take more care with an upload. If CloudRepo stored a file and the answer was lost on the way back, a
second upload of the same path meets 409 Conflict while
Overwrite Protection is on, because the file is already there. On a
Maven repository a file in a -SNAPSHOT version directory, maven-metadata.xml and its checksum and signature files are
the exceptions: a second upload of one of those is accepted and replaces the first. See
Maven: SNAPSHOT and Metadata Are Exempt. Check
whether the file exists before you publish it again.
Keep what your builds have downloaded
Section titled “Keep what your builds have downloaded”Maven keeps what it downloads: its local repository is a directory on the machine that “caches remote downloads”. On CI, where each job starts clean, use your CI platform’s cache feature to keep that directory from one run to the next, so a fresh job starts with what an earlier one downloaded.
Keep your own copy
Section titled “Keep your own copy”A build can only use what it can fetch. For releases you cannot rebuild, keep a copy of your own. See Backup and Recovery.
Next steps
Section titled “Next steps”- Troubleshooting: what each status code means.
- Backup and Recovery: keep your own copy.
- Support: how to write to us.