feat: Add Github Actions

[maiquanghiep]

No description provided.

[filippos47]

Great effort!
Overall, a bit frustrating that we need to introduce a separate tagging convention just for a single service type (nodejs). Are there any alternatives that do not affect the tagging? @jrwbabylonlab

This also breaks the automated devnet deployment for the simple-staking service on babylon-service-deployment:

https://github.com/babylonlabs-io/babylon-service-deployment/blob/330243364dd7f984e337bd00069b50c87423c5e2/.github/workflows/commit-schedule-checker.yml#L82

[jrwbabylonlab]

Great effort! Overall, a bit frustrating that we need to introduce a separate tagging convention just for a single service type (nodejs). Are there any alternatives that do not affect the tagging? @jrwbabylonlab

This also breaks the automated devnet deployment for the simple-staking service on babylon-service-deployment:

https://github.com/babylonlabs-io/babylon-service-deployment/blob/330243364dd7f984e337bd00069b50c87423c5e2/.github/workflows/commit-schedule-checker.yml#L82

Not i'm aware of. FE deployment is always quite different to others as it does not dynamically accept envs.
All code/env need to be ready at build time as webpack will bundle them together

[vitsalis]

lgtm, although this again introduces coupling between a service repository and an internal deployment. No problem with merging this now, but we should remove the tight coupling from here.

[filippos47]

As we discussed offline, we can merge this for now.
The next iteration involves templatizing the extra publish logic into the reusable publish workflow.

[jrwbabylonlab]

@maiquanghiep it's best to squash merge. otherwise we end up with too many random commits

[maiquanghiep]

@jrwbabylonlab Sorry my bad, selected squash but forgot to do the same after reloading the page