Add indicator that a PR has been included in the latest staging build

[patersonc]

At the moment, as documented the staging pipeline automatically goes through each relevant kerrnelci repository and tries to merge valid pull requests into a staging.kernelci.org branch for each repository.

These branches are then used in a "staging" version of kernelci.org - staging.kernelci.org.

The process occurs every 8 hours and it works great.

However, when there are lots of PRs for the same repository there is always a chance that there may be a merge conflict. If this happens the branch/PR being merged will be ignored. When this happens there is no way for the user to know that their PR hasn't been picked up by staging in the GitHub GUI unless they look through the commit log.

The goal for this ticket is to add a visible way to determine whether a PR is part of the latest staging.kernelci.org build.

This could be done by adding a new in-staging label, or by adding a comment, or both, or some other method.

[gctucker]

When this happens there is no way for the user to know that their PR hasn't been picked up by staging in the GitHub GUI unless they look through the commit log.

Actually there is one way, by looking at the staging.kernelci.org branch history:
https://github.com/kernelci/kernelci-core/commits/staging.kernelci.org

But of course it's not very easy to use, and having a notification would be better than constantly keeping an eye on this branch.

[gctucker]

About labels, maybe we could have this workflow:

• staging-skip set by hand as currently done, to explicitly exclude a PR. That's useful when it breaks something in particular.
• staging-merged set by the bot when the PR has been merged into the staging.kernelci.org branch
• staging-conflict set by the bot when the PR has some conflicts, and as a result was not merged

There is one more step between merging the PRs and deploying the resulting staging branch, because some patches are being applied on top of it. So even if a PR doesn't conflict and gets merged, it may not be deployed if a patch has a conflict. In this case, I think a notification on IRC or email on [email protected] would be good as no staging jobs are running when it happens.

[patersonc]

Makes sense.

Do we remove the staging-merged label once the PR has been merged? Or if the staging-skip label is subsequently added?