W-23599683: CI/release artifact naming convention

[mlischetti]

Problem

The customer-downloadable CI artifacts and release assets are named three
inconsistent ways (observed on
run 30393123015):

• OS casing — Linux/Windows (from ${{ runner.os }}) vs
  linux/windows (from ${{ matrix.script_name }}), in the same run.
• Architecture — present only on the Python wheels; absent from the CLI
  distro, Node .tgz, and dwlib, even though every artifact today is x86_64.
• Base-name clarity — native-cli-…-native-distro repeats "native"; the
  Node .tgz never says "node"; nothing distinguishes it from the Python
  package.

Convention

Every artifact except the Python wheel now follows:

<base-name>-<version>-<os>-<arch>.<ext>

• <os> — lowercase, from ${{ matrix.script_name }} (linux/windows)
• <arch> — derived at runtime (ARCH=$(uname -m)), so it stays correct if an
  arm64 runner is ever added
• Base names — dw-cli (the dw executable), dataweave-node (the npm
  package), dwlib (the shared library + header)

Resulting artifacts (x86_64 today):

dw-cli-100.100.100-linux-x86_64.zip        dw-cli-100.100.100-windows-x86_64.zip
dataweave-node-0.0.1-linux-x86_64.tgz      dataweave-node-0.0.1-windows-x86_64.tgz
dwlib-100.100.100-linux-x86_64             dwlib-100.100.100-windows-x86_64
dataweave_native-0.0.1-py3-none-manylinux2014_x86_64.whl   …win_amd64.whl  (exception)

Changes

• main.yml / ci.yml — derive ARCH; rename the CLI distro (via a cp
  staging step, mirroring the existing Node staging step), the Node .tgz, and
  the dwlib artifact. Under archive: false the artifact name is the file's own
  name, so renames happen at the file/path: level; the dwlib step keeps
  name: (it stays archived — multiple files).
• release.yml — align every asset_name: to the convention; fold ARCH
  into the existing version step.
• scripts/check-artifact-names.sh — a validation script asserting the
  convention (lowercase OS, arch present, correct base names, no runner.os in
  names) plus YAML well-formedness. Used as the local red→green gate while
  building this change.

Deliberate exceptions (by design, not oversights)

• Python wheel keeps its setuptools PEP 427 name. In release.yml its
  asset_name: is removed and file_glob: true added so it uploads under its
  real name; the CI wheel step is untouched. A renamed wheel breaks
  pip install / platform resolution.
• release.yml if: runner.os == 'Linux'/'Windows' conditionals are kept —
  they gate which OS uploads .so vs .dll. The validation script ignores
  if: lines when forbidding runner.os in names.
• The dwlib .h header in release.yml keeps dwlib-<version>.h (no
  os/arch — the header is platform-independent).

Pre-existing bug fixed

release.yml's Python-wheel upload pointed at …-py3-none-any.whl, but the
build produces a platform-tagged wheel (manylinux2014_x86_64 / win_amd64),
so the step could not find the file. Changed to …-py3-none-*.whl +
file_glob: true.

Verification

Can't be exercised locally — GitHub Actions runs only on CI. check-artifact-names.sh
is the local gate (all three workflows pass). True confirmation is the next
master CI run (main.yml/ci.yml) and the next v* tag (release.yml):
verify the produced names and that no upload-artifact name-collision fires.

Out of scope / follow-up

• macOS & arm64 builds — the code produces a .dylib, but no macOS/arm64
  runner is in the matrix. The convention is arm64-ready; adding those builds is
  separate.
• Wiring check-artifact-names.sh into CI — it's committed as a manual dev
  tool today; adding a lint step that runs it against the three workflows would
  turn the casing-drift guard into an enforced gate. Suggested follow-up.

🤖 Generated with Claude Code