0

I have two repositories A and B, both hosted on GitHub.

  • Repo A is static site generator code.
  • Repo B is bunch of text files.

They have to stay separate. I want to rebuild repo A, each time repo B receives an update. It has to work using GitHub Actions only. I'd prefer if repo B would stay action-less, i.e. no CI/CD attached to that repo (I want it to store only files). I was thinking maybe I can make it work using git submodules? Repo B would be a submodule within Repo A. Is it possible to build GH action within repo A, to detect changes in repo B and pull from there?

edit: Repo A is Static-site generator(nextjs) I'm intending to share with public. Repo B is full of text files(org-roam) which a user brings with themselves. Together they build a personal wiki website. I'd want to minimize the configuration hassle - that's why I want to have all CI/CD and code encapsulated in Repo A, so the user could just fork it, and plug-and-play it with their knowledge base repository (repo B). Having intertwined GitHub Actions between two repositories seems not ideal - that's why I'm searching for better solution

Marcin
  • 179
  • 2
  • 14
  • 1
    You can use a `repository_dispatch` action on a workflow from the repo B (that will be updated) to trigger another workflow on repo A. Here is a good reference to start using it: https://blog.marcnuri.com/triggering-github-actions-across-different-repositories/ (I've implemented it this week and it worked great!) – GuiFalourd Mar 30 '21 at 19:17
  • 1
    GuiFalourd's solution is the best way imo. If you really want to keep B action-less, you could run an action in repo A on a schedule and check for changes. – riQQ Mar 30 '21 at 21:17
  • Thanks @GuiFalourd and @riQQ ! Yes, `schedule (cron)` GA seems to be the only way to do it if I'd want to encapsulate all CI/CD related steps in repo A, and I'm not fond of this solution (a lot of waste). One thing I'm also considering is setting up `webhooks` inside repo B, which would trigger repo A via `repository_dispatch`. Would something like that work? Are there any drawbacks in comparison to having `GA` in both repositories? I updated the question for complete the picture of my situation. My feeling is webhooks would be a lil bit simpler to setup for end user. – Marcin Mar 30 '21 at 23:49
  • 1
    nope - webhooks solution does not seem to be possible, because I can't really modify/shape the request that's being sent from repo B – Marcin Mar 31 '21 at 00:28
  • It would probably be easier to have everything in the same repo so anybody could fork it and have all datas at their disposition. But I understand your point in keeping separated what would be commum to everyone. In that case I still think repository_dispatch will be better as everyone will be able to fetch the repo when updated anyway. Moreover, you can send a body with the dispatches requests if you want to send specific datas from one repo to the other (it is explained in the link I shared in the first comment). – GuiFalourd Mar 31 '21 at 12:15

1 Answers1

1

thanks to @GuiFalourd and @riQQ , I was able to put together proof-of-concept set of repositories

Both repo share same GitHub Personal Access Token. To fill the blanks from the blog.marcnuri.com guide, here is minimal set of permissions required to make this work (given both repositories are public, otherwise you need repo permission: enter image description here

Marcin
  • 179
  • 2
  • 14
  • why did you deleted these repositories? I really would like to know how you solved this problem. – David Sep 23 '21 at 07:06
  • my apologies @David, I changed visibility back to public – Marcin Sep 23 '21 at 15:45
  • Cute drawings, the only problem is that you are sending your access token to an external repository, that's NOT so cute. I suggest modifying the comment about repository permissions in this answer emphasizing this behavior. – Karmavil Mar 23 '22 at 06:29