this epic tracks our efforts to build an inner dev loop that helps us test upstream and unmerged changes on downstream builds

• a PR is merged in operator / pac / any upstream project we care about
  AND
  the PR is merged in any tracked branch in upstream_sources.yaml in all release branches
  THEN
  a downstream build is built and posted on #pipelines-bots channel
  • the downstream builds will come from 2 sources:
    • cpaas and CVP
    • internal builds
  • both of these builds will be identical enough to test all bugs/features

• • implementation:
    • the branches tracked in upstream_sources.yaml are tracked by the sync upstream sources job anyway, however that's a cron job and it's a pain to manage - we should move to a watcher based solution that watches the github events of the repository https://docs.github.com/en/rest/activity/events and we look for push events there.

• a PR is merged in operator / pac / any upstream project we care about
  OR
  a developer wants a downstream build from their fork or any commit really
  THEN
  they should be able to trigger a pipeline from gitlab/p12n repo with whatever to get a downstream build
  • this should probably not be automated as most of these might never be used
  • UX to request a custom build should be a slack command to a bot 🤖

• • implementation:
    • first we want the ability in the operator to accept commits / forks / branches to do builds.
    • then we want a UX like a CLI or a slack bot or a slack form to trigger the builds based on inputs like commit, branch, etc

• ❓ in PAC and downstream operator and upstream operator 🎉, we can run this part of their upstream CI but not on other tekton upstream projects
  • when a PR is opened in PAC then a downstream build is posted as a comment on that PR
  • PAC tests are run on a downstream operator build built from operator main branch

• these builds can be tested on cluster pools provided by hive