CI: Extract and don't hardcode artifact naming

[cprecioso]

Description

• As part of CI: Generate npm packages #3464

---

• I extracted the computation of the artifact and tarball name out of the waspc-build workflow, so that we can reuse it in multiple places (mainly, the fetch-nightly-packages; and in the future the npm packaging script) without repeating ourselves.
• Makes the waspc-build job output the computed names of the artifacts it has created. This way we don't hardcode these names in the following workflows.
  • This requires a bit of a workaround since, in matrix jobs, each job will override the output. Instead, we store each job's output in a different variable.

Type of change

• 🔧 Just code/docs improvement
• 🐞 Bug fix
• 🚀 New/improved feature
• 💥 Breaking change

Checklist

• I tested my change in a Wasp app to verify that it works as intended.

• 🧪 Tests and apps:

  • I added unit tests for my change.
  • (if you fixed a bug) I added a regression test for the bug I fixed.
  • (if you added/updated a feature) I added/updated e2e tests in examples/kitchen-sink/e2e-tests.
  • (if you added/updated a feature) I updated the starter templates in waspc/data/Cli/templates, as needed.
  • (if you added/updated a feature) I updated the example apps in examples/, as needed.
    • (if you updated examples/tutorials) I updated the tutorial in the docs (and vice versa).

• 📜 Documentation:

  • (if you added/updated a feature) I added/updated the documentation in web/docs/.

• 🆕 Changelog: (if change is more than just code/docs improvement)

  • I updated waspc/ChangeLog.md with a user-friendly description of the change.
  • (if you did a breaking change) I added a step to the current migration guide in web/docs/migration-guides/.
  • I bumped the version in waspc/waspc.cabal to reflect the changes I introduced.

[cloudflare-workers-and-pages]

Deploying wasp-docs-on-main with    Cloudflare Pages

Latest commit:	935a6bf
Status:	✅  Deploy successful!
Preview URL:	https://6f38d859.wasp-docs-on-main.pages.dev
Branch Preview URL:	https://cprecioso-separate-workflows.wasp-docs-on-main.pages.dev

View logs

[infomiho]

Left some comments

[infomiho]

On the fence if we need this comment, for example, you are not explaining the fromJson API for Github Action etc.

But I'm okay if we keep it 👍

RAW

[infomiho]

Something feels off about using $i here for me. I asked some of my LLM buddies to help me with some suggestions:

1. You could use for i in "${!input_files[@]}"; do to get the array indicies which lets you do tar -xzf "${input_files[$i]}" -C "arch-$i".
2. Another suggestion was to go fully explicit with something like:

   set -ex
   
   # Create semantic directories
   mkdir x86_64 aarch64 universal
   
   # Extract specifically to those directories
   tar -xzf "$X86_64_TARBALL_NAME" -C x86_64
   tar -xzf "$AARCH64_TARBALL_NAME" -C aarch64
   
   # Create the universal binary
   # Now it is obvious which inputs are being used
   lipo -create x86_64/wasp-bin aarch64/wasp-bin -output universal/wasp-bin
   
   # Copy data from one of the sources (explicitly choosing x86_64)
   cp -R x86_64/data universal/
   
   # Pack back up
   tar -czf ${{ steps.compute-artifact-names.outputs.tarball-name }} -C universal .

[infomiho]

I found the second option the most readable since this is an exact thing we are doing: creating 1 universal binary out of Intel and ARM binaries. We don't need the extensibility here, it'll always be that.