|
| 1 | +# CBMC release process |
| 2 | + |
| 3 | +This document outlines the current release process in a summary form. |
| 4 | + |
| 5 | +## Part I |
| 6 | + |
| 7 | +1. PR with version label change to `src/config.inc` and `src/libcprover-rust/Cargo.toml`. |
| 8 | + To be merged after CI has run. |
| 9 | + * We update both with the same version after a decision had been made to keep both |
| 10 | + projects to the same version number. For more info on versioning, please take a look at |
| 11 | + `doc/ADR/release_process.md` |
| 12 | + |
| 13 | +2. After the PR has been merged, pull develop locally and spin off a tag with |
| 14 | + `git tag -a cbmc-<version>`. After some wait, this is going to trigger building |
| 15 | + Linux && Windows jobs and submit PR to [`homebrew`](https://formulae.brew.sh/formula/cbmc) |
| 16 | + and image to [`docker`](https://hub.docker.com/r/diffblue/cbmc/tags). |
| 17 | + * The release creation is being driven by the `.github/workflows/regular-release.yaml` file, |
| 18 | + which creates a new release with some template text filled in. |
| 19 | + * After the release has been created, another github action starts building the |
| 20 | + binaries, driven by the `.github/workflows/release-packages.yaml`. |
| 21 | + |
| 22 | +## Part II |
| 23 | + |
| 24 | +1. Tap release performed next day depending on when homebrew formula has been updated. |
| 25 | + Process outlined at `doc/ADR/homebrew_tap.md`. |
| 26 | + * The process usually goes as follows: we give homebrew about a day after the release |
| 27 | + has been created to merge the PR updating the formula on their end, and for the |
| 28 | + bottles (binaries) to be built. |
| 29 | + * We update the `brew` database locally, and then extract the formula as outlined |
| 30 | + above (should be a command like `brew extract cbmc@version`). |
| 31 | + * After the formula has been extracted, we need to fetch the binaries they have built |
| 32 | + and edit the formula to contain the binaries and their hashes. We usually use |
| 33 | + the script [`transform_binary.sh`](https://github.com/diffblue/homebrew-cbmc/blob/main/transform_binary.sh) |
| 34 | + which downloads the bottles on the local folder and then gives us their hashes |
| 35 | + to edit the formula with. The end result looks like this: [Example formula](https://github.com/diffblue/homebrew-cbmc/commit/97e539b25465077304c6e8c01400b708511ed5ee) |
| 36 | + * Last bit is to commit the formula and push it to the tap, and edit the release to |
| 37 | + add the downloaded binaries as release artefacts. This last bit is just an edit |
| 38 | + of the `bag-of-goodies` release from the Github UI, and then a drag-and-drop of |
| 39 | + the binaries into the upload form. |
| 40 | + |
| 41 | +2. Crates.io release which is really just a cargo publish with the environment |
| 42 | + variables the Rust build requires. Process outlined at https://docs.rs/crate/libcprover_rust/latest. |
| 43 | + * Usually this is just a `cargo publish --dry-run` first, waiting to see that |
| 44 | + the build is successful and that the command is aborting right before the |
| 45 | + build is uploaded, and then just performing a `cargo publish` which pushes |
| 46 | + the crate. |
0 commit comments