Skip to content

Development

Develop a new feature or fix a bug

  1. Initialize an own branch from dev branch
  2. Develop a feature or bugfix itself
  3. Open a PR against dev branch.
  4. Trigger an image build when playbooks were edited or upgrade testing environment when workflows were edited
  5. Test the playbook functionality
  6. Create a PR against the production branch
  7. Wait until an image is produced automatically in case of playbook changes
  8. Upgrade production repositories when workflow templates were changed

We will provide more details about some steps below:

Starting branch

Playbook case

To develop a new feature, a developer has to start from upstream-community-dev branch in playbooks by creating their own branch.

Make sure that the development branch upstream-community-dev is synchronized with production one upstream-community.

Workflow case

The development branch which is your base branch is ci/dev. Please make sure that the development branch ci/dev is synchronized with the production branch ci/latest.

Never edit production workflows directly, which are located in .github/workflows directory. Your changes will be lost during the next pipeline upgrade - during the next feature implementation.

PR to dev branch

Playbook case

When a feature/bug fix is ready, please open a PR against upstream-community-dev branch.

There aren't any valid unit tests, just obsolete ones. You can ignore failure there. The only valid test is linting, which should pass.

Workflow case

Open a PR against ci/dev branch.

Image build trigger

Playbook case

To build an image from just edited playbooks, trigger it by GH action called Build playbook image

Click Run workflow on the top right and select a branch. In this case upstream-community-dev.

The functionality allows triggering image build from the feature branch also, however, the naming convention should be like upstream-community-dev-[something].

In both cases (upstream-community-dev-[something] and upstream-community-dev) your action will produce quay.io/operator_testing/operator-test-playbooks:dev image.

Workflow case - repo upgrade

No need to build any image. To populate edited workflow templates to the testing project, please execute Upgrade GH action. Set branches which you want to test. The standard setup is ci-dev and upstream-community-dev.

Test a playbook funkcionality

To test a currently implemented feature, one or more test cases need to be set. The only test which is expected to fail is ci/prow/4.8-pipeline-functionality. There is a space for improvement to make the test work as a quality gate for Prow job workflow file changes.

Back to tests, we should focus on. We will test the following parts of the test suite: - Basic PR tests - Temp index test - Prow test - Release test

Basic PR tests

To execute all basic PR tests, please edit a description in an operator in the test pipeline environment. Please do not add more operators if not necessary, it can increase the repository size for workflow templates. We recommend editing just a description in an operator. Push to your branch on your own GH repository. Then open a PR. This corresponds with the setup of how contributors work against the community repositories.

Prow test

Every PR triggers a Prow test no matter if it is K8S or OCP. This is a standard setup only for community-operators-pipeline pipeline. Production pipelines run Prow only if needed. More information on where to find the Prow debug log is here.

Temp index test

When prow fails it can be due to a missing temporary index or temporary bundle. Temp index and the bundle are processed by Prepare Test Index workflow. Logs are directly available. If you are not sure to which PR is workflow run related, check Build temp index and push stage. You should see something like Preparing temp index for PR: 347.

Release test

When all tests are green, expect ci/prow/4.8-pipeline-functionality as mentioned above, we can test release by merging the PR. Then a release can be checked directly here, we expect a green result.

Create a PR against the production branch

Now you are in the phase to create PRs from dev to production for both playbooks and framework:

Open and merge community-operators-pipeline:ci/dev to community-operators-pipeline:ci/latest. Do not apply it by Upgrade procedure next steps are completed to the state that a new playbook image is out.

Open a PR from operator-test-playbooks:upstream-community-dev to operator-test-playbooks:upstream-community.

Wait until an image is produced automatically in case of playbook changes

After it is merged, just wait until Build playbook image pipeline has finished.

Upgrade production repositories when workflow templates were changed

Now, it is time to apply workflows by running CI Upgrade on production OCP and k8s production.

Failure is not bad if workflows should stay as it is, it just means nothing was changed. If there should be changes, investigate why no change is present.

Add a feature with an automatic comment to a PR

In some cases, it is very useful to notify a contributor directly to a PR thread. We are using github.issues.createComment action. It is used many times, one example bellow:

with:
  github-token: ${{secrets.GITHUB_TOKEN}}
  script: |
    github.issues.createComment({
      issue_number: context.issue.number,
      owner: context.repo.owner,
      repo: context.repo.repo,
      body: 'Current PR can be merged automatically, but there is missing `authorized-changes` label. One can find out more info [here](https://${OPP_THIS_REPO_ORG}.github.io/${OPP_THIS_REPO_NAME}/operator-ci-yaml/#reviewers).'
    })