Add a GHA to generate the two root folder JSON files and push to the gh-pages branch

[swcurran]

Currently, a PR to update an OCABundle must execute the GHA to generate the root level JSON bundles — which is a pain. A better solution would be to have a GHA that does that on each merge. That too is a bit of a pain if the GHA has to push the result back to the protected main branch. I think a good way to resolve this is to have a GHA generate the files and push them to the gh-pages branch such that they get published to the GH Pages along with the OCA Explorer. They would be removed from the main branch.

The impact of this is that all of the software that relies on the current location of the JSON files would have to be updated to use the new location. That’s OK for now — we can manually keep the JSON files up to date on main as well for a short time while the transition is made.

[swcurran]

@esune -- since this is a breaking change, I'd like to get this done sooner than later so that we break fewer installations.

I think the GHA should be trivial...

[swcurran]

Realize that the JSON files in the root and the OCA Bundles must have the same root path, so if the generated file is on a different branch, the OCABundles folder must also be copied onto the that branch.

So options that I see:

• Somehow make the GHA generate the JSON files so that they continue to be on main in a way that contributors putting in PRs don't see/edit the files. I'm not sure if that is a permitted pattern, but I could be wrong.
• Generate the files onto another branch and copy the OCABundles folder onto that branch as well. If doing this one, probably best to use the gh-pages branch so that later (in a different PR) we can put the site documentation onto the branch (and hence, published to a website), and we can move the OCAExplorer onto that same branch.

[esune]

For the purpose of updating ocabundles.json and ocabundleslist.json I wonder if a post-merge action that updates the main branch would suffice (something like this). The only question I have is about the DCO sign-off signature, since it will be an automated agent, but my guess is that is won;t be required OR there should be something that can be used as "signer"...

[swcurran]

Not that the example you pointed to does NOT update main, but deliberately targets another branch. I think targetting main for such automation is difficult, because a user may or may not update the targetted files. We explicitly DON’T want the files updated manually, because we want the READMEs updated. Perhaps possibly, but I think it is messy.

Regards DCO, I know we do this in Hyperledger, so it must be possible.

Hmmm….as I write this, I realize that the daily AATH GHA targets main. We could look at what it does.

https://github.com/hyperledger/aries-agent-test-harness/blob/main/.github/workflows/generate-summary-results.yml

The painful part of that one is that it runs on cron and the PR is created everytime. We want to trigger on a merge, so that it was generated right after a merge.

[esune]

I'm sure we can use the pr merge as a trigger and then, if necessary, go through the creation and automatic merge of a new PR (if it goes down to that).

[swcurran]

Yes — easy minimum. I’ll look at the larger idea of using gh-pages branch. I need to understand combining mkdocs-material and OCA Explorer on a single site. I think I know how to do it, but need to verify. I’ve never done GHA development — in particular, how to do local testing.

[esune]

For local testing, this might help (not for every scenario though): https://github.com/nektos/act

[swcurran]

Addressed in #115