c/ooni-probe-cli
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[ci skip] doc: explain staging branches and binary builds (#604)

Browse Source 
The text I've written here documents the current process as of
today. The only major change I've added today is the `miniooni-staging`
branch, which previously wasn't published and only lived in the
private machine I was using for building `miniooni`.
This commit is contained in:
Simone Basso 2021-11-17 09:24:10 +01:00 committed by GitHub
parent 0cb535b022
commit 20679702a3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 39 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
CONTRIBUTING.md
View File

@ -125,12 +125,43 @@ port, the commit message should start with `[forwardport]`.
When we branch off release `x.y` from `master`, we also need to bump When we branch off release `x.y` from `master`, we also need to bump
the `alpha` version used by `master`. the `alpha` version used by `master`.
None of the branches described so far automatically publishes any In addition we have `PRODUCT-staging` branches for each product. These
binary package. To publish binary packages we use the `PRODUCT-staging` branches are described below:
branches (e.g., `mobile-staging`). To trigger these builds, we merge
from a release branch into the desired `PRODUCT-staging` branch. This
design ensures that we only publish binary packages when we want to
do so. Because we merge from a release branch, we are not pushing alpha
code to binary releases. (The only exception to this rule is `miniooni`,
treated differently because it's an `alpha` client.)
- `miniooni-staging`: branch for building and publishing `miniooni`
binaries. This branch marges from the `master` branch when we tag
alpha releases. We use this strategy because `miniooni` is an alpha client.
We publish the resulting binaries in alpha releases.
- `mobile-staging`: branch for building and publishing iOS and
Android releases of the `pkg/oonimkall` library. This branch
merges from the release branches or the release tags. We use this
strategy because mobile releases are either beta quality or
production quality releases. We publish the resulting binaries
in beta quality or stable releases.
- `oohelperd-staging`: branch for building and publishing `oohelperd`
binaries. This branch merges from the release branches or the
release tags. We use this strategy because `oohelperd` releases
are either beta quality or production quality releases. We
publish the resulting binaries in OONI's internal Debian repository.
- `ooniprobe-staging`: branch for building and publising `ooniprobe`
binaries. This branch merges from the release branches or the
release tags. We use this strategy because `ooniprobe` releases
are either beta quality or production quality releases. We
publish the resulting binaries both in beta quality or stable
releases and in OONI's public Debian repository.
Builds proper happen either in this repository, using GitHub
actions, or using private build machines. Sometimes we need
private build machines to inject specific secrets into the
binary (e.g., we currently use this to inject OONI's Psiphon config).
Additionally, we currently publish as Github Actions artifacts
`miniooni` binaries for selected Linux architectures for
each commit that lands into the `master` branch. You will
find those binaries [in the results of each individual build](
https://github.com/ooni/probe-cli/actions/workflows/miniooni.yml)
until they are automatically removed by GitHub compatibly with
the build assets retention period (should be 90 days).