[WIP] GitHub action to deploy OCI image for tags

[s373nZ]

IMPORTANT: Read the plan below and if agreeable, create a dmnd branch and set it to the main branch. After that, this PR should be edited to merge into dmnd, not master.

This work aims to help with deploying new versions of the sv2-tp template provider by acting on new GitHub tags to run Pulumi. A few thoughts about how the DMND fork could be structured and the corresponding workflow:

• Create a new dmnd branch in the repository and designate it as the "main branch".
• Updating new code from the stratum-mining/sv2-tp upstream directly should take special care to go to master.
• Deployments for this first iteration are a manual process requiring explicit developer intervention:
  1. When a new release tag is observed, developer should fetch the tag to their local machine.
  2. Rebase the dmnd branch against that tag to capture the latest changes along with the workflow definition.
  3. Tag the new commit with the same tag name as the upstream and push it to the demand-open-source/sv2-tp repository to trigger the workflow and deployment.

There is some room to rethink how to manage the code updates from upstream (scheduling, using merges for example), but there is at least one major limitation; the workflow code must exist in the branch or tag in order to run it under GitHub Actions. I suspect some degree of trial and error over time would be beneficial before settling on too complex a solution. Hopefully what is here is helpful toward getting updated code deployed for the Template Provider.

In following iterations, we can explore:

• Keeping the upstream tags synchronized on a schedule, and performing the merge and tag push automatically.
• Approaches for automatically generating change sets and pull requests to the main DMND pool repository.

[jbesraa]

Is this ready for review?

[s373nZ]

Is this ready for review?

I think it's worth a look, but up to you. Sounds to me like getting an updated version of the Template Provider up for testing is a high priority, so I wanted to push something workable early.

I'm continuing to explore scheduling and a more automated approach for merging our build process into the upstream changes.

[jbesraa]

I am not fully sure why we need to maintain 'dmnd' branch. Can elaborate please?

[s373nZ]

I am not fully sure why we need to maintain 'dmnd' branch. Can elaborate please?

I'm not sure I have a 100% bulletproof answer for you, as I'm still working toward a better overall solution. The idea with the dmnd branch was to keep updates from upstream to our master isolated from our own overrides (contained in dmnd), keeping the same commit hash. Otherwise, updates from upstream result in a merge commit, which might be ok, but automatically put our repo into a different tree / commit history from the upstream.

major limitation; the workflow code must exist in the branch or tag in order to run it under GitHub Actions

Either way, our tags will be a different Git commit hash from the upstream, since they need to include the workflow code in order to run it. So, using master could be an option if you like.

Haven't been able to fully think through all the consequences yet, so thought trying to contain our changes in a dmnd branch would be a good conservative start.