Skip to content

High Availability

View as Markdown

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.

Troubleshooting maps each status code to its usual cause. Two groups matter here:

  • 401, 403, 404 and 409 are 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.

Let your tools try again on a failure that is not a refusal:

  • curl retries a transient error when you pass --retry with a number. The default is no retries.
  • pip retries a connection it cannot establish: --retries sets how many attempts, and the default is 5.
  • npm retries idempotent read requests on a network failure or a 5xx: the fetch-retries setting, default 2, sets how many.
Terminal
curl --netrc --fail --retry 3 --output hello-copy.txt \
https://your-org.mycloudrepo.io/repositories/your-repo/uploads/hello.txt

Retry 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.

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.

A build can only use what it can fetch. For releases you cannot rebuild, keep a copy of your own. See Backup and Recovery.