It has been argued that the API files provide value for verifying that code changes produce API changes in the expected way. This helps devs and reviewers. It has also been argued that the CI job adds friction and forces devs to configure their environment unnecessarily. Both viewpoints have some merit. Lets remove the API files for now, and when we start doing 1.0-alpha releases and can start to expect minimal API breaking changes (and therefore minimal need to use the tooling). |
||
|---|---|---|
| .. | ||
| README.md | ||
| cargo-semver-checks-version | ||
| coveralls.yml | ||
| cron-daily-fuzz.yml | ||
| cron-daily-kani.yml | ||
| cron-weekly-cargo-mutants.yml | ||
| cron-weekly-rustfmt.yml | ||
| cron-weekly-update-cargo-semver-checks.yml | ||
| cron-weekly-update-nightly.yml | ||
| cron-weekly-update-stable.yml | ||
| gh-release.yml | ||
| manage-pr.yml | ||
| miri.yml | ||
| release.yml | ||
| rust.yml | ||
| semver-checks-pr-label.yml | ||
| semver-checks.yml | ||
| shellcheck.yml | ||
| stable-version | ||
README.md
rust-bitcoin workflow notes
We are attempting to run max 20 parallel jobs using GitHub actions (usage limit for free tier).
ref: https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration
The minimal/recent lock files are handled by CI (rust.yml).
Jobs
Run from rust.yml unless stated otherwise. Unfortunately we are now exceeding the 20 job target. (Prepare is quick and must be run first anyway.)
PrepareStable - minimalStable - recentNightly - minimalNightly - recentMSRV - minimalMSRV - recentLintDocsDocsrsBenchArch32bitCrossEmbeddedASANWASMKaniCoveralls- run bycoveralls.ymlrelease- run byrelease.ymllabeler- run bymanage-pr.ymlShellcheck- run byshellcheck.yml