Use proxy workflow and commit statuses to record testing results

[islas]

TYPE: enhancement

KEYWORDS: testing, devops, github, workflow

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The CI/CD testing framework using github actions is set to trigger on PR label events. However, labels are not just used for testing and will trigger the workflow. While the workflow does have checks in place to skip any labels that aren't meant to trigger testing, this skipped workflow status will override any previous actual test status. This can be confusing if two labels are applied at the same time, one being a test label, and only one status appears showing a skipped workflow. Unique naming of workflow runs does not mitigate this problem as the posted status is tied to the workflow internal id and not the run name.

Solution:
Convert the main workflow that hosts the test sets into a dispatch workflow, meaning it must manually be triggered. This has the intended effect of decoupling the workflow id from any PR and will not normally show up as a status at the bottom of PRs solving the issue of independent labels overriding each other. To solve the workflow no longer appearing within PR statuses, the github REST API is used to create a commit status pointing to its respective workflow run via target_url along with the current state of the job.

As the main workflow must manually be triggered, a new entry point proxy workflow is used to filter test labels and request a test run if needed. This paradigm allows events to be triggered within a PR context, simplifying gathering the data necessary to run the correct PR branch. Furthermore, the entry point will still suffer the initial problem of status override on multiple labels, but this should be acceptable as actual test labels will create their own commit statuses once queued.

The dispatch workflow is unable to be run within the context of PR merge refs, nor the head of the branch from a fork (as that would run the workflow in that fork). Thus, the dispatch workflow is run using the base ref of the PR if from a fork, or the head ref ONLY IF originating from the parent repo of the workflow. This means testing of the immediate changes to the workflow can only be observed within the PR of an internal repo branch, limiting development slightly. The benefits, however, are a cleaned up status reporting AND increased security as no runner code that isn't already within a branch of the repository will be executed. One should still ensure the underlying tests are okay to run

TESTS CONDUCTED:

1. Testing was done in independent fork to demonstrate initial issue and feasibility of this solution.

[islas]

As noted in the PR description, only internal branches can be used to immediately see workflow changes in effect. That is why this PR is coming from actions_testing

Further detail on this strategy can be read in 91f918b

Examples of this running can also be found in islas#10 to see a mock test failure

[weiwangncar]

The Jenkins test results:

Test Type              | Expected  | Received |  Failed
= = = = = = = = = = = = = = = = = = = = = = = =  = = = =
Number of Tests        : 23           24
Number of Builds       : 60           57
Number of Simulations  : 158           150        0
Number of Comparisons  : 95           86        0

Failed Simulations are: 
None
Which comparisons are not bit-for-bit: 
None

[islas]

@amstokely When you have a moment, could you review this?

[amstokely]

I still can't believe this much effort is needed for something that should be simple. That said, based on past experience (unfortunately 😞), this is the most reliable way to handle it.