Project structure: re-organization?

[astro-angelfish]

I do always feel bad to refer another repository that seems not to be related to this repository. They are aiming at different areas but only things in common is they are documents that we need to translate and publish to the same website.

Maybe we might need to refactor the whole repository structure to keep the maintainability of repositories. I'll research configurations about CI/CD as long as the idea of refactoring is accepted. Or this issue could be closed as unplanned.

Things to be done:

• [x] Get accepted or just close unplanned
• [ ] Create a central publish repository
• [ ] Update CI/CD and commit changes to publish repository
• [ ] Use CI/CD to automatically deploy the changes that are committed to publish repository

You may just need to use emoji reaction to notify me whether you agrees this idea.

[CloneWith]

Looking into this owo

[CloneWith]

I do always feel bad to refer another repository that seems not to be related to this repository.

This made me accidentally came up with a few disadvantages of sub dictionaries:

• Licensing. License files are included by default in the document structure and there isn't a clear way to resolve it.
• Revision changing and updating. After sub-repo updates, you need to manually change the reference in the main repo.
• Cannot run overall remark or test deployment on pure Markdown repos, making some vulnerable changes hard to find out.

Don't worry about the acceptance, your idea seems pretty right. High five on approving it.

[NaughtyChas]

• [ ] Create a central publish repository

I was never quite sure what was meant by ‘central repository.’ In its current structure, ‘osu-dictionary’ already functions as a central repository. When a PR or a new commit is pushed to the main branch, GitHub Actions are triggered to build the page to GitHub Pages.

From a CI/CD perspective, we already use version control and automated builds within our workflow, and the unit testing framework relies on simple GitHub Actions test builds. Therefore, our main repository should be capable of continuous delivery.

I noticed that the organization has created a repository named ‘atriiiiiiiiiiiiiiiiinterface’ for storing static HTML code of the page. Does this mean we need to move our workflow from GitHub builds to self-builds?

It would be helpful if you could explain a bit about the structure of the new architecture. Looking forward to your reply @astro-angelfish.