git checkout $(git show -s --pretty='%T' $(git show-ref -d $(git describe --abbrev=0) | tail -n1 | awk '{print $1}')) -- test; make -j4 test

```

We use labels to keep track of which branches a commit should land on:

* `dont-land-on-v?.x`

* For changes that do not apply to a certain release line

* Also used when the work of backporting a change outweighs the benefits

* `land-on-v?.x`

* Used by releasers to mark a PR as scheduled for inclusion in an LTS release

* Applied to the original PR for clean cherry-picks, to the backport PR otherwise

* `backport-requested-v?.x`

* Used to indicate that a PR needs a manual backport to a branch in order to land the changes on that branch

* Typically applied by a releaser when the PR does not apply cleanly or it breaks the tests after applying

* Will be replaced by either `dont-land-on-v?.x` or `backported-to-v?.x`

* `backported-to-v?.x`

* Applied to PRs for which a backport PR has been merged

* `lts-watch-v?.x`

* Applied to PRs which the LTS working group should consider including in a LTS release

* Does not indicate that any specific action will be taken, but can be effective as messaging to non-collaborators

* `lts-agenda`

* For things that need discussion by the LTS working group

* (for example semver-minor changes that need or should go into an LTS release)

* `v?.x`

* Automatically applied to changes that do not target `master` but rather the `v?.x-staging` branch

Once a release line enters maintenance mode, the corresponding labels do not

need to be attached anymore, as only important bugfixes will be included.

* Architecture labels

* `arm`, `mips`, `s390`, `ppc`

* No x86{_64}, since that is the implied default