GitHub Actions adoption blockers for the Azure SDK

The purpose of this issue is to keep track of any adoption blockers for GitHub Actions use by the Azure SDK. The following list is a set of features from Azure Pipelines that Azure SDK depends on to run its engineering system. For each item we try to provide sufficient detail as to why we depend on it. Over time, as GitHub Actions matures and provides _analogues_ we'll strike these items off the list with links to any relevant detail. The hope is that eventually enough blockers will be removed that experimentation becomes worthwhile.

# Templating

We make extensive use of almost all features of the Azure Pipelines templating syntax. We use input parameters into templates to generate jobs, tasks, and stages on the fly (e.g. we give a list of packages in our entry-point YAML) and we get a stage generated for each package.

Example: https://github.com/Azure/azure-sdk-for-java/blob/6955838cd94dba6d1b51fe806f0c1032c8485ccf/eng/pipelines/templates/stages/archetype-java-release.yml#L50

Beyond the meta-generation of pipelines based on pipeline parameters we need approval gates mechanisms that include things like multi-person approvals, timeouts etc.

# Build artifacts

We use Pipeline Artifacts to pass artifacts from stage to stage. Typically we produce unsigned packages in our build and then sign them in a later stage. We also have error handling which will result in a snapshot of the repository being uploaded for inspection if a build fails. The ability to have pipeline/workflow associated collections of files is essential.

# Logging

We have tooling which allows us to analyze causes of failures over time. One of the things that I've noticed in the GitHub Actions API is that there is no mechanism to fetch the log output for just a single step, it seems to just work at the job level. Is this correct?

# Test result publishing

We make use of the test result publishing to provide an easy to navigate interface to look into things like test failure rates and test execution times (we do this for most of our mono-repos).

# Private/secure Builds

For each ```ci.yml``` template in our repository, we have two pipeline definitions in Azure DevOps which point to it. This is done for security reasons. We want to make it so that external contributors can submit a pull request and we perform basic validation such as building the code and running it through our playback tests.

However, we also want to be able to run pipelines that have access to secrets. We achieve this by having a second set of pipelines defined in our internal team project which _team members_ can trigger using ```/azp run``` commands. This allows us to avoid someone outside the team using a pipeline to exfiltrate secrets.

Given sufficient security controls we would welcome simplifying this, but we cannot have a situation where it is possible for someone to access a secret in our pipelines. We need to be able to control in what context secrets are made available to pipelines.

# Secrets management at scale

Secrets management in general is an issue. We make extensive use of KeyVault to store and manage our secrets. And then we using variable groups linked to KeyVault to expose those secrets to pipelines. This simplifies the management of secrets across a very large number of pipelines (hundreds).

# Large agent pools

We are currently planning to adopt the 1ES Managed Pools (based on scale sets) to handle our build volumes. If we were to adopt GitHub Actions we would either need to be confident that we would not get blocked from getting the capacity we need (like we are currently with AzDO hosted pipelines), or have 1ES have a similar solution to what they are building for AzDO).

# Random adoption pain

The items have represent the issues that we know we are likely to have adopting GitHub Actions. But we also expect that there will be quite a few unknowns that won't surface until we start peeling the onion. We would in effect be rebuilding the orchestration elements of our engineering system. We have also been adding mobile support into our system and we know of multiple shortcomings in the mobile space with respect to Github Actions.