You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Multiple endpoints --remote-store and --write-store can we support multiple S3 buckets? #130
Reading and writing can already go to different buckets:
BITS_REMOTE_STORE=b3://prod # reuse everything production has built
BITS_WRITE_STORE=b3://pr # PR builds land only in the PR bucket
A PR then rebuilds only what it changes, and production is never written to. What this doesn’t do is let a second pipeline on the same PR reuse the first one’s builds from the PR bucket. Those packages, the changed ones and the ones that depend on them, get rebuilt on every push.
One caveat - this works only if both buckets share same credentials since S3 connection settings are global in bits.
The stores should be searched in the order specified: first PR, then PROD, and finally COMMON. If a package is not found in one store, the next store should be checked.
Similarly, the write-store configuration should depend on the release type:
This would allow PR builds to reuse packages already available in Production or COMMON while keeping the write destinations specific to the release type.
Credentials:
Variables are BITS_S3__ACCESS_KEY_ID, …_SECRET_ACCESS_KEY and optionally …_SESSION_TOKEN, …_ENDPOINT_URL, …_REGION, …_ADDRESSING_STYLE.
The bucket name is upper-cased, with other characters turned into _.
Alternatively, a [bucket cms-pr] section in ~/.bits/s3keys holds the same keys.
A bucket with nothing of its own uses the usual settings, so single-store setups work as before.
Recipes never see any of these credentials.
Reading: stores are tried in order, and the first one that has a package wins. A store that errors or can’t be reached is skipped with a warning.
Writing: every built package is uploaded to every write store, and a failed upload to any of them fails the package. Packages reused from a store are not copied to the write stores.
Revision numbers: they are chosen from the markers of all read and write stores, so the stores never give one number to two different packages.
Signed reuse: it applies to every read store, using each store’s signed manifests. A PR-bucket copy of a certified package is reused. A package that only a PR build produced isn’t certified, so it is rebuilt unless the PR job uses --no-require-signed-reuse. That choice affects only that job.
Other commands:
bits publish, bits store upload and bits compliance work on every store in the list.
bits certify publishes to each store and certifies the build once, from the first store.
bits gc sweeps each store against its own signed manifest (one --trust-manifest per store).
bits doctor, bits status --check-store and bits checksums look at every store.
Activity
pbuncic commentedon Oct 17, 2026
You can set BITS_REMOTE_STORE, BITS_WRITE_STORE to different value depending on pipeline type (PR or production).
Release pipeline: BITS_REMOTE_STORE=b3://prod, BITS_WRITE_STORE=b3://prod.
PR pipeline: both set to b3://pr.
Reading and writing can already go to different buckets:
BITS_REMOTE_STORE=b3://prod # reuse everything production has built
BITS_WRITE_STORE=b3://pr # PR builds land only in the PR bucket
A PR then rebuilds only what it changes, and production is never written to. What this doesn’t do is let a second pipeline on the same PR reuse the first one’s builds from the PR bucket. Those packages, the changed ones and the ones that depend on them, get rebuilt on every push.
One caveat - this works only if both buckets share same credentials since S3 connection settings are global in bits.
Would this work for you?
akritkbehera commentedon Oct 20, 2026
For example, if a package is available in Production but not in PR, we should be able to retrieve it using the following remote-store configuration:
The stores should be searched in the order specified: first
PR, thenPROD, and finallyCOMMON. If a package is not found in one store, the next store should be checked.Similarly, the write-store configuration should depend on the release type:
PRandCOMMON.--write-store b3://cmsrep/PR;;b3://cmsrep/COMMONPRODandCOMMON.--write-store b3://cmsrep/PROD;;b3://cmsrep/COMMONThis would allow PR builds to reuse packages already available in Production or COMMON while keeping the write destinations specific to the release type.
Several read and write stores, each bucket with its own credentials
pbuncic commentedon Oct 24, 2026
Implemented in 4ad968c, 4109ac4 and 205681e on orchestration.
Both options (and REMOTE_STORE/WRITE_STORE) now take comma-separated lists, and each bucket can have its own credentials and endpoint:
Credentials:
Variables are BITS_S3__ACCESS_KEY_ID, …_SECRET_ACCESS_KEY and optionally …_SESSION_TOKEN, …_ENDPOINT_URL, …_REGION, …_ADDRESSING_STYLE.
The bucket name is upper-cased, with other characters turned into _.
Alternatively, a [bucket cms-pr] section in ~/.bits/s3keys holds the same keys.
A bucket with nothing of its own uses the usual settings, so single-store setups work as before.
Recipes never see any of these credentials.
Reading: stores are tried in order, and the first one that has a package wins. A store that errors or can’t be reached is skipped with a warning.
Writing: every built package is uploaded to every write store, and a failed upload to any of them fails the package. Packages reused from a store are not copied to the write stores.
Revision numbers: they are chosen from the markers of all read and write stores, so the stores never give one number to two different packages.
Signed reuse: it applies to every read store, using each store’s signed manifests. A PR-bucket copy of a certified package is reused. A package that only a PR build produced isn’t certified, so it is rebuilt unless the PR job uses --no-require-signed-reuse. That choice affects only that job.
Other commands:
bits publish, bits store upload and bits compliance work on every store in the list.
bits certify publishes to each store and certifies the build once, from the first store.
bits gc sweeps each store against its own signed manifest (one --trust-manifest per store).
bits doctor, bits status --check-store and bits checksums look at every store.
pbuncic commentedon Oct 26, 2026
Does this work for you? If so, please close the issue.
Orchestration (#143)