Propagate workflow updates automatically

[ghost]

Currently, whenever the workflow needs to be updated in the content repos, we need to push the diff to a whole bunch of different repos (~10) and branches (~5 per repo).

So far, my tools of choice have been git-format-patch and git-am:

1. git format-patch -1 SHA
2. Edit the file names in the patch file to match the content repos.
3. cd repo
4. Repeat as necessary:b='branch_name'; git checkout "$b" && git am /patch/to/0001-patch_file.patch && git push
5. Go to next repo, skip back to (3.)

Cons:

• It takes a while until I'm through with it all.
• It's easy to forget certain repos/branches, because there's no defined list.
• It's hard to explain this to anyone else in a way that they'll actually get it right.

Pros:

• I can vary the way I apply it per repo. Notably helpful for doc-cloud, where you need to create a PR rather than being allowed to push straight through.

Ideas:

• Take the current workflow, but make it a script that is hosted in this repo and can be updated whenever new branches appear/old branches become irrelevant. Then run on a client machine as necessary. Issue: The script depends on the names of local clone dirs and local file name structures that are different for every person potentially executing this.
• Take the current workflow, run it via GH Actions from this repo, and open PRs in the target repos. Issues: a bit more complicated (though doable), requires large amounts of PR merges, can't interactively deal with conflicts.
• Run a web hook/GitHub Action in downstream repos and have downstream repos try to update on their own (similar to https://stackoverflow.com/questions/23793062). Issues: more complicated, decentralized (imo in the wrong way), requires large amounts of PR reviews, can't interactively deal with conflicts.

[ghost]

@tomschr in #44:

---

Situation

We've tried to modularize our processes and did a decent share with GitHub Actions (GHA). When we've started with GHA, we weren't able to reuse workflows, only Actions.

Now it's possible to share GitHub workflows. The GitHub workflow contains these lines at the beginning:

on: 
  workflow_call:
    inputs:
      # defines the inputs of this workflow

jobs:
  # contains all the jobs and their steps to complete this workflow

To "call" this workflow in another workflow, use jobs.<job_id>.uses like this:

jobs:
  build:
    uses: openSUSE/doc-ci/.github/workflows/build.yml@main
    # pass inputs of the workflow with the "with" keyword

It's possible to use a different branch or SHA as we've done so for GHA already.

Be aware, reuse of workflows are currently in beta and subject to change.

Suggestion

We should look into this topic again and decide, if it can help to refactor our process workflow and deduplicate GHAs.

References

• Reusing workflows
• Advanced GitHub Actions (video from GitHub Universe, starting around 10min)

[ghost]

From the linked docs, #Limitations:

• Any environment variables set in an env context defined at the workflow level in the caller workflow are not propagated to the called workflow. For more information about the env context, see "Context and expression syntax for GitHub Actions."
• The strategy property is not supported in any job that calls a reusable workflow.

Not sure if I read this right but both of those limitations sound like they'd kill this for us:

• We need an environment variable for the gha-publish job.
• We need the strategy property for parallelizing jobs.

[tomschr]

From the linked docs, #Limitations:

• Any environment variables set in an env context defined at the workflow level in the caller workflow are not propagated to the called workflow. For more information about the env context, see "Context and expression syntax for GitHub Actions."
• The strategy property is not supported in any job that calls a reusable workflow.

Not sure if I read this right but both of those limitations sound like they'd kill this for us:

* We need an environment variable for the `gha-publish` job.

* We need the `strategy` property for parallelizing jobs.

The limitation on the strategy property isn't mentioned anymore.

Regarding the environment variables, I don't know. Perhaps it could be passed as an input. :shrug: