Dependabot PRs is Running on Publish CI

[matttrach]

When Dependabot generates PRs they are running in both drone-publish and drone-pr. They should only be running on drone-publish.

[matttrach]

The dependabot PRs are running on both drone-pr and drone-publish, since they’re using branches on the main repo. We should update the drone config to not run publish CI on branches other than master and release-*

[matttrach]

RKE2 Repos:

• [x] https://github.com/rancher/rke2
• [x] https://github.com/rancher/image-build-base
• [x] https://github.com/rancher/image-build-calico
• [x] https://github.com/rancher/image-build-cni-plugins
• [x] https://github.com/rancher/image-build-containerd
• [x] https://github.com/rancher/image-build-coredns
• [x] https://github.com/rancher/image-build-crictl
• [x] https://github.com/rancher/image-build-dns-nodecache
• [x] https://github.com/rancher/image-build-etcd
• [x] https://github.com/rancher/image-build-flannel
• [ ] https://github.com/rancher/image-build-ib-sriov-cni
• [ ] https://github.com/rancher/image-build-k8s-metrics-server
• [ ] https://github.com/rancher/image-build-kubernetes
• [ ] https://github.com/rancher/image-build-multus
• [ ] https://github.com/rancher/image-build-rke2-cloud-provider
• [ ] https://github.com/rancher/image-build-runc
• [ ] https://github.com/rancher/image-build-sriov-cni
• [ ] https://github.com/rancher/image-build-sriov-network-device-plugin
• [ ] https://github.com/rancher/image-build-sriov-network-resources-injector
• [ ] https://github.com/rancher/image-build-sriov-operator
• [ ] https://github.com/rancher/image-build-whereabouts
• [ ] https://github.com/rancher/image-build-node-feature-discovery
• [ ] https://github.com/rancher/system-agent-installer-rke2
• [ ] https://github.com/rancher/rke2-upgrade
• [ ] https://github.com/rancher/rke2-packaging
• [ ] https://github.com/rancher/rke2-selinux
• [ ] https://github.com/rancher/rke2-charts

[matttrach]

• Example problem: https://drone-publish.rancher.io/rancher/rke2/2960
• The publish CI is running because Dependabot's commit is merging with Dependabot's branch, neither of which are master.
• This normally doesn't happen because the workflow for humans is to fork and request merge, so nothing ever merges on a branch before the PR.
• If we make sure that all CI steps look only at main/master and release-*, then we will be ignoring any merges to branches that we don't publish from. This will allow Dependabot to run from a local branch rather than a fork (a different workflow than contributors).

[matttrach]

To implement this we need to add a when clause to the steps which points to the main/master and release-* branch. example:

  when:
    ref:
      include:
        - "refs/heads/master"
        - "refs/heads/release-*"

The when clause's main objects must all evaluate to true for the CI to run, but sub objects are OR, so in the above example ref must be true for the CI to run, but ref = true if any of the include items are true. This means that the CI will run if the ref path includes refs/heads/master OR refs/heads/release-*. The ref object is not compatible with the event tag sub-object because tags are not associated with a branch. This means that if the when clause includes and event tag object we should not add a ref object, these carry the assumption that they are only on the master/main branch. Most steps carry either the event tag or ref objects already, so we can safely exclude those.

[matttrach]

https://docs.drone.io/yaml/exec/#the-when-section https://docs.drone.io/yaml/exec/#the-conditions-object https://docs.drone.io/yaml/exec/#the-include-attribute https://docs.drone.io/yaml/exec/#the-ref-attribute https://docs.drone.io/yaml/exec/#the-event-enum https://docs.drone.io/pipeline/conditions/#by-branch

[matttrach]

ref is where the object comes from branch is where a pull or push wants to go to

[matttrach]

The context of ref is where the CI is pulling from, this is sent to Drone via the webhook.

The ref will therefore be one of these three paths:

• refs/heads/* infers a push/merge event and the ref is a commit on the branch that accepted the merge
• refs/tags/* infers a tag event and the ref is to the tag
• refs/pull/* infers a pull_request event and the ref is to the special GitHub branch that contains the PR in your repo

[matttrach]

Events (tag, push, pull_request) to Instances (PR, Publish)

• We don't want the PR instance to react to push or tag events
• We don't want the Publish instance to react to pull_request events
• We do want the Publish instance to react to tag and push events
• We do want the PR instance to react to pull_request events

tag = Publish, tag != PR push = Publish, push != PR pull_request != Publish, pull_request = PR

Publish = tag && push PR = pull_request

[matttrach]

Steps to Events:

• Some steps should run on all events (ex. build, test)
• Some steps should run on all instances (ex. build, test)
• Steps shouldn't share instance and event
  • we rely on the webhook configuration make sure this is true
  • you must be an org admin to see the webhook configuration
  • the webhooks should be set up so that tag and push events are sent to only the Publish instance
  • the webhooks should be set up so that pull_request events are sent to only the PR instance
    • this means that we can infer the instance type by the event type

[matttrach]

Refs to Events and Instances:

• a ref is where (in Git history) the CI will pull from to run steps
• there are three types of refs: head, tag, and pull
  • each type of ref relates directly to the corresponding event type
    • a push event will have a head ref
    • a tag event will have a tag ref
    • a pull_request event will have a pull ref
• since instances can be inferred by event type, and ref type directly relates to event type then we can relate instance to ref

[matttrach]

Steps to Refs:

• Some steps should run on tag, pull, and head refs, but only for main/master and release branches (ex. build, test)
• Some steps should run on only tag refs (ex. verify release)
• Some steps should run on only head and pull refs (ex. skip files)

We can infer events and instances by ref, there is only one ref for a pipeline, so we can control any step by ref.