CI/CD strategy

Most of the release process should be automated, this is why we configured GitHub actions to run different jobs.

PR validation strategy

  1. On each PR (and when new commits arrive) and on push on main, cargo build and cargo test are run to make sure everything is working
  2. On each git tag, we will run a CI job to test, build and run cargo publish to release PLX on crates.io

GitHub workflow

  1. We protect the main branch on the main repository to avoid pushing commits directly without any review. The 2 others repository (website + organisation profile) are not protected for ease of change.
  2. For each feature or change:
  3. we create a new issue and assign it to the correct person
  4. create a new branch,
  5. try to follow the conventionnal commits standard for writing commit messages,
  6. when done we send a PR.
  7. The PR is automatically merged only after one review, and trivial changes that do not review can be merged by the PR creator.
  8. Github is configured to block merging if CI jobs are failing.
  9. We try to delete the branch when PR is merged.

contributing

Release strategy

To release a new version of PLX, here are the manual steps:

  1. Create a new release branch
  2. Choose a new version number based following semantic version
  3. Modify the CHANGELOG.md to document changes since last release
  4. Modify the Cargo.toml with the chosen version
  5. Run cargo build to update the duplicated version number in Cargo.lock
  6. Push the changes
  7. Open and merge PR of this release branch (tests must pass so we cannot release code with compilation errors)

The CI release job starts and detect a version change (version in Cargo.toml different from the latest git tag) so the release process start

  1. Create a new tag with the extracted version
  2. Create a new release on Github with a link to the CHANGELOG.md
  3. Run cargo publish to publish plx on crates.io

The result is that running cargo install plx again will install the new version!

workflow