Trigger azure-pipelines.yml via GitHub Action

[thekaveman]

This has some overlap with #284 and so will need to coordinate, possibly building on top of the work done there.

A single GitHub repository can be associated with multiple Azure DevOps organizations/projects:

Once the GitHub App is installed, pipelines can be created for the organization's repositories in different Azure DevOps organizations and projects.

From Azure docs: Build GitHub repositories.

But the docs go on to say (emphasis mine):

However, if you create pipelines for a single repository in multiple Azure DevOps organizations, only the first organization's pipelines can be automatically triggered by GitHub commits or pull requests. Manual or scheduled builds are still possible in secondary Azure DevOps organizations.

So in order to deploy to multiple Azure DevOps orgs (i.e. MST and SBMTD), we're going to need to trigger the azure-pipelines.yml run manually, via GitHub Actions.

Further, (if possible) it would make sense to trigger every org's pipeline in the same way, e.g. not have one of the DevOps orgs setup for "automatic trigger by GitHub commits or pull requests" like mentioned in the docs above. Each org should deploy via the GitHub Action.

Note manually here does not mean literally a human clicking a button to trigger a workflow. It means we'll need a GitHub Actions workflow (that acts on e.g. tag, to accommodate what is needed for #284) that then triggers the pipeline.

[angela-tran]

This task may not be necessary based on some findings from my experiments documented in https://github.com/cal-itp/eligibility-server/issues/284#issuecomment-1688736156

I noticed that my commits to ... branch [#307] were triggering both the real MST DevOps pipeline as well as another DevOps pipeline I created in our separate compilerllc organization. This doesn't match the documentation that Kegan linked to in https://github.com/cal-itp/eligibility-server/issues/294 which says that only the "first" organization's pipeline will be triggered by commits or pull requests.

[angela-tran]

Once #346 is merged in, I suggest that as our next step we set up an Azure DevOps pipeline in SBMTD's organization and see if GitHub commits / pull requests automatically trigger in both MST and SBMTD or just one. That will help us decide if we need to do this ticket or not.

[angela-tran]

I ran several experiments to help us decide if we need to do this ticket or not. In my first experiment, I made a test commit - 750d85f - on the feat/sbmtd-infra-pipeline branch. In my second experiment, I opened #352. Both experiments resulted in only triggering the MST pipeline.

This behavior matches what the Azure docs say.

I'm not sure what difference was causing the behavior described in https://github.com/cal-itp/eligibility-server/issues/294#issuecomment-1734642840. You can see that both MST and Compiler LLC pipelines were being triggered if you notice that the Azure pipelines link in #307 goes to mstransit (though the build unfortunately no longer exists) and that there is a corresponding build in Compiler LLC.

But anyways, the point is that our current configuration behaves such that we need to do this ticket. 👍

[angela-tran]

Today we tried out merging #349 into dev, and it triggered a pipeline run in each organization

[thekaveman]

The pipelines do run in each org when a PR is merged against our deploy branches dev, test, prod :+1:

However we only get the plan run for a PR being opened against the deploy branches for the first org (MST). Hence we'll still need an action workflow to at least trigger the plan.

[thekaveman]

Pausing for now -- we can apply changes to multiple orgs, which was the main goal.

As we make more progress on #282 our thinking / procedure here may change.