ci: from jenkins to github action

[pdesoyres-cc]

Fixes #625

Fixes #627

Fixes #637

[github-actions]

🔎 A preview has been automatically published:

• 🐧 linux 981f3bb2b53b6b687a480c375ba7bbf826cdbd3196551c418d64b26cefbbb7bb
• 🍏 macos c00c8d5b365647c23e6427bafbf1fc1fa0caf954fc4e7b3a7ff3bfed905ca72d
• 🪟 win 04a62aa12d33374743ea04a8c5b073d695129ed9ea7d010ba8ecb46fc00a6354
  This preview will be deleted once this PR is closed.

[hsablonniere]

Hi @pdesoyres-cc,

😍 What you did with this PR is amazing!! Well done 👏

I wrote a few remarks. I have one real concern but I'm not sure if it's blocking. Let me explain.

To build the bundle or not...

I was expecting the build to only build (with pkg) but not generate the archives (tar.gz, zip) and not create the bundles (rpm, deb). Therefore, I was expecting the preview links to directly refer to the binaries and not the archives. I guess what you did is a bit cleaner and smaller.

I would be OK to keep building the archives and using them for the preview links but I'm not sure we need to build the bundles for every PR as we don't do anything with them. In a way what you did ensures a PR cannot be merged if the bundles build breaks somehow so maybe we should keep it...

The only problem I have is I failed to install fpm on my system and cannot run the build job locally.

WDYT? Should we keep it as is?

About Docker Hub

Your PR does the same thing as what we did for Docker: create a commit and push it. It used to trigger build and publish on Docker's infra but it's not the case anymore. We should update the task so it builds the docker image and publishes it to the hub.

Can you create a separated issue for this?

Commits

• This needs to be rebased on latest master
• Do we want to keep this full history?
  • We could fixup the refactor and chore commits but if it's too much work, don't bother it's already good as is

[pdesoyres-cc]

Bundle or not bundle during the build phase?

• I agree that having to install fpm even though we don't need the result is pointless.
• In the meantime, I also like the build job to verify as many things as it can.

I have 2 propositions:

• add a parameter to the job-build.js to skip the bundling phase.
  • we could go further and add another parameter that skips the archive phase which you also don't need locally.
  • locally, you could just do something like node scripts/job-build.js --skip-bundle --skip-archive
• another proposition is to remove the bundling phase from the job-build.js but add job-bundle.js which only bundles.
  • locally you'll then run node scripts/job-build.js and it doesn't bundles.
  • we need to add the bundling phase to the build GitHub action.
  • the advantage is that we can install the dependencies needed by the bundling phase after the build, which may make the workflow fail faster in case of build failure.

I'm ok with both propositions, just let me know if you prefer one or another.

[pdesoyres-cc]

• I rebased on master
• I plan to squash all commits. Is it ok for you? @hsablonniere

[hsablonniere]

@pdesoyres-cc

• OK to squash all commits
• Let's go for option 2 with opt-in

[github-actions]

🔎 The preview has been automatically deleted.