Recent change in the ci Pipeline

TL;DR: Plugin maintainer need to adjust merge requirements.

A large change in the plugin template has been merged:

This change consists of two interesting changes:

  1. It uses composable/reusable workflows to better structure how the ci runs.
  2. It adds a build step that builds a wheel from the plugin code that is used for testing it. Previously we installed plugins directly from source. This is the first step in an effort to test closer to what we ship and to make the build process shared between PR, nigthly and release workflows.

The biggest visible change is that the workflow names changed a bit, and that means the new names must be adjusted in the branch protection rules (settings->branches->main->edit->Require status checks to pass before merging).

1 Like

Another change that landed is changing the behavior of the single commit check.

While most often, a PR should be a small change contained in a single commit, There are valid exceptions. To avoid, on the other hand, the accidental merge of fixup commits, we kindly ask the contributor to squash their commits into a single one (or into a small number of reasonable ones accordingly). The single commit check was there to help us reviewers see when it was time to take a closer look. But it was always looking like multi commit pr’s were forbidden. This recent change will instead of a failed-but-ignored test present the multi commit case nicely with a label. So please when reviewing be on the lookout for this label and see whether squashing commits were required.

Sidenote: By the way patchback operates on our repositories, bugfix PR’s must always come with a single commit. But honestly, fixing one bug is one story and should be done in one commit anyway.

1 Like

Thanks for working on this!

If a PR contains two or more commits, the following label is added to it:

Colour code: #FFD700

1 Like