Use pull requests to update the library

[josecelano]

Relates to: nautilus-cyberneering/chinese-ideographs#103 (comment)

The library repo triggers a workflow in this repo when a new commit is pushed to the main branch in the library. This was we can update the website if images are changed in the library.

Right now we only have one workflow: import-base-images.yml.

That workflow updates the submodule (library), imports the images, generates the JPEG images, makes the auto-commit for the new or updated images in the public/images folder and finally generates the auto-commit for the submodule update.

One of the problems with that approach is that we can end having an inconsistent scenario:

1. We make the image commit but we fail to make the library update commit.
2. We fail to make the image commits but we make the submodule update commit.

Depending on if we first add the images commit or the submodule commit. The second scenario is worse because we are not going to process those images again.

We think that by using a branch we could avoid this non-atomic update of the main branch and maybe other concurrency problems. The solution we thought was to create a new branch and PR on this repo with a unique name (something like update-base-images-from-library-378acd13e3a98a39a231d0f2ff35a4f885ce3d6c-4165442861, update-base-images-from-library-LIBRARY_NEW_COMMIT_SHA-WORKFLOW_ID_THAT_TRIGGERED_THE_IMPORT) and let git resolve merge conflicts. We also need to think about how to solve more complex problems like having more than one dependant workflow on the website, for example, importing radicals from the same library. How to solve those problems is out of the scope of this issue. So I think we can merge it as it is.

[josecelano]

I have created a proof of concept in an independent repo: auto-update-submodule-poc

[josecelano]

We've discarded this option because:

• It makes the process more complex. You have to deal with automatically merging PRs.
• There is a GitHub Action to create PR but commits are not signed

We decided to use scheduled workflows that act as workers. They work on a local git branch on the runners and they directly push to the main branch. It's going to be implemented in this issue.