Skip to content

Latest commit

 

History

History
103 lines (63 loc) · 6.5 KB

CONTRIBUTING.md

File metadata and controls

103 lines (63 loc) · 6.5 KB
Raw

redhatci.ocp

Prerequisites

Clonning the repository

To be able to run the sanity tests, the recommended way to extract the repository is like this:

$ cd <your workspace>
$ mkdir -p ansible_collections/redhatci
$ cd ansible_collections/redhatci
$ git clone [email protected]:redhatci/ansible-collection-redhatci-ocp.git ocp
$ cd ocp
...

Sign commits

Follow this documentation to sign your commits

For traceability and delivering software in a secure manner this repository requires all the commits to be signed (not to be confused with sign-off). Because of that, don't edit or rebase from the GitHub UI as it will not be signed doing it this way.

Running the sanity tests locally

The sanity tests are run using the ansible-test tool. It comes from the ansible-core package. This is what is run in the CI pipeline.

$ ansible-test sanity --verbose --docker --color --coverage --failure-ok

Legacy code is expected to fail some sanity tests. The ask is to not introduce new failures and fix the errors in the legacy code when you are modifying it. It is an iterative process to clean up the legacy code.

Pull Requests

The collection is using the GitHub Flow for the development. The main branch is main. The main branch is protected and requires a PR to be merged. The PRs are reviewed by the maintainers of the collection.

Keep the PRs small and focused on a single topic. Write a good commit message. It is easier to review and merge. It also helps to keep the git history clean. Keep as few commits as possible.

When updating a PR follow these approaches:

  1. Use git commit --amend and git push --force to update the PR. It will update the PR automatically. Do this when you iterate by yourself on a PR. When someone else has reviewed the PR, it is better to create a new commit to keep the history of the PR.
  2. Squash the commits when you are ready to merge the PR.

PRs can be created as a Draft, use this when the change is not yet ready for review or set a PR to Draft if it needs more time before continuing with the review process.

Ready for review

Your PR is considered ready for review if all the CI checks are green. If you don't want a review yet, convert your PR to a Draft.

Bumping the version

The collection is continuously built and published to Ansible Galaxy. The versioning scheme used is Semantic Versioning with an automatic PATCH number to allow to publish automatically. This PATCH number is the UNIX epoch time of the last commit. This allows to publish a new version of the collection every time a change is merged to the main branch.

The version is defined in the galaxy.yml file and ansible-collection-redhatci-ocp.spec. To bump the version (MAJOR or MINOR), edit these files and commit the change.

Edit MAJOR when there are breaking changes in the collection. Edit MINOR when there are new features added to the collection.

CI pipelines

The collection has multiple CI pipelines that run on every PR:

  • PR pipeline: .github/workflows/pr.yml that runs the sanity tests and Ansible lint. It fails if there is any regression. It also runs a check on the PR Dependencies (Depends-On: lines in the commit message) to make sure that the dependencies are merged before the PR.
  • DCI BOS2 pipeline: .github/workflows/dci.yml that runs a DCI job to test the collection in a virtual environment at the BOS2 Telco Partner CI lab. It is triggered only when a change is modifying files in the /roles/ directory.
  • DCI Dallas pipeline: run DCI jobs on a baremetal cluster in the Telco Partner CI Dallas lab. It is triggered automatically only when changes are modifying files in the role/cnf-cert or roles/preflight directories.
  • RPM build pipeline (local/check). This is managed by the Zuul CI on https://softwarefactory-project.io/. It builds rpm for el8 and el9.

To specify which DCI lab to use and which resources to use, you can use the following strings in the descrption of the PR:

  • TestDallas: baremetal clusters in the Dallas lab.
  • TestDallasWorkload: workload on a pre-installed baremetal cluster in Dallas.
  • TestBos2: virtual setup in the BOS2 lab.
  • TestBos2Sno: virtual SNO setup in the BOS2 lab.
  • TestBos2SnoBaremetal: baremetal SNO node in the BOS2 lab.

The following Test-Hints can be specified if needed in the description of the PR:

  • Test-Hint: no-check when no test is needed in DCI. For a doc only change this is detected automatically.
  • Test-Hint: force-check to bypass the automatic no code change detection. Useful for CI testing.

Examples:

TestDallas: ocp-4.14-vanilla example-cnf
TestDallasWorkload: preflight-green
TestBos2: virt control-plane
Test-Hint: force-check

At least one check needs to pass for the PR to be validated.

Reach out to the Telco Partner CI team if you need more information.

Merge Queue

There is a set of CI pipelines that are run just before merging by the merge queue mechanism of GitHub. This allows to validate the merged PR before pushing them to main. This is important to avoid parallel merge of PRs that would break the collection.

Issues

We welcome feedback! Open issues filling out as much as possible in the issue template. Providing an accurate way of reproducing the issue is critical in helping us identify the problem quicker.

Before opening a new issue, please use the search feature to see if someone has not reported something similar. If there is an open issue you're experimenting and have additional information, please comment. Using "thumbs up" in an issue help us to give an indication on how many people is facing that problem.