Building this repository using webhook

[Shaikh-Ubaid]

Looks like it can be done: https://kontent.ai/blog/how-to-trigger-github-action-using-webhook-with-no-code/

  # Allows external webhook trigger
  repository_dispatch:
    types:
      - webhook

Originally posted by @certik in #3 (comment)

[Shaikh-Ubaid]

This is the missing piece that we need to (I guess) figure out and then (hopefully) things should work, that is:

• if there are commits in lfortran master, the CI in this repository should get triggered and the site dev.lfortran.org should get updated.
• if there are commits in lcompilers_frontend, the in this repository should get triggered and the site dev.lfortran.org should get updated. (This already works).

[Shaikh-Ubaid]

doubt: Please, could someone possibly share if it should be the wasm_builds repository triggering the CI of this repository? Because the resources needed by this repository to build are available at wasm_builds, so until wasm_builds completes its build and deploy stages, we are unable to fetch the required files.

[certik]

Right. Probably that's right. Note that there is a delay when publishing to the GitHub pages.

[Shaikh-Ubaid]

Right. Probably that's right. Note that there is a delay when publishing to the GitHub pages.

Got it. Thank you for the clarification.

[certik]

Just setup the webhook from lfortran --- after it pushes the commit into wasm_builds.

[certik]

I think we have time at our CI due to the Windows build. So add 60s delay after "git push to wasm_builds", so that GitHub has enough time to publish the page, then issue the "webhook" from the same CI task at LFortran. That should work robustly.

[Shaikh-Ubaid]

I think we have time at our CI due to the Windows build. So add 60s delay after "git push to wasm_builds", so that GitHub has enough time to publish the page, then issue the "webhook" from the same CI task at LFortran. That should work robustly.

Got it.

[Shaikh-Ubaid]

This work flow https://github.com/lfortran/wasm_builds/actions/runs/2878330373 at wasm_builds took around 1 min, 7 secs. It seems 60 secs may not be robust. Shall we wait 120 secs?

[certik]

Yes. And I wonder if we should not do automatic updates like this --- it seems very fragile.

We could create a PR after 120s in this repository, that updates the hash. Then we do not need to setup any webhooks, we just create a PR, and the CI in this repository will run and upload a testing website and we can manually review that everything works, and then just merge manually.

And if we want things to work automatically, we can later set "merge if pipeline succeeds" button at the PR.

So I think that is a better design, more robust. What do you think?

[Shaikh-Ubaid]

What do you think?

It seems #24 might be a possible solution.

We could create a PR after 120s in this repository, that updates the hash. Then we do not need to setup any webhooks, we just create a PR, and the CI in this repository will run and upload a testing website and we can manually review that everything works, and then just merge manually.

Automated commits might/would have looked nice. Though, this approach also seems fine.

[certik]

I am not opposed, but I am worried about the complexity / fragility. It's hard to add just one latest commit automatically, so far we didn't manage. So the PR approach seems like something that we can manage, and we can iteratively improve it (up to and including full automation), while being 100% robust at every step all the time.