Matrix macOS ARM64 binary releases for R 4.3/4.4/4.5 with versioned asset naming

[Copilot]

The macOS ARM64 binary workflow only produced a single R 4.4 artifact (Hotgenes_X.X.X.tgz), which is incompatible with downstream publishing that expects per-R-version assets. This updates the workflow to build and publish binaries for R 4.3, 4.4, and 4.5 using the required naming convention.

• Workflow matrix

  • Converted build-macos-arm64 into a matrix job over r-version: ["4.3", "4.4", "4.5"].
  • Kept existing checkout/setup/dependency/build flow intact per matrix leg.

• Artifact naming contract

  • After R CMD INSTALL --build ., the generated .tgz is renamed to:
    • Hotgenes_{package_version}_R{r-version}_macOS-arm64.tgz
  • Exposes BINARY and PKG_VERSION via $GITHUB_ENV for subsequent release steps.

• Release coordination across matrix jobs

  • Release creation is gated to the 4.4 job.
  • 4.3 and 4.5 jobs wait for the release to exist, then upload their matrix-specific artifact.
  • Upload uses gh release upload ... --clobber to avoid duplicate-name collisions on reruns.

strategy:
  matrix:
    r-version: ["4.3", "4.4", "4.5"]

# after build
BINARY_RAW=$(ls Hotgenes_*.tgz | head -n 1)
PKG_VERSION=$(grep '^Version:' DESCRIPTION | awk '{print $2}')
BINARY_RENAMED="Hotgenes_${PKG_VERSION}_R${{ matrix.r-version }}_macOS-arm64.tgz"
mv "$BINARY_RAW" "$BINARY_RENAMED"

Original prompt

Context

Open-Hotgenes is a public R package (pfizer-opensource/Open-Hotgenes) with a macOS ARM64 binary build workflow. The current workflow only builds for R 4.4 and produces assets named Hotgenes_X.X.X.tgz.

A companion publishing script (publish_binaries.R) will be added separately and it expects assets named with the pattern: Hotgenes_{version}_R{rv}_macOS-arm64.tgz for each R version (4.3, 4.4, 4.5).

---

Change — .github/workflows/build-macos-arm64-binary.yml

Current workflow issues:

1. Only builds for R 4.4 (hardcoded in setup-r)
2. Asset is named Hotgenes_X.X.X.tgz — no R version or platform in the name
3. Single job, no matrix

Required changes:

1. Add a matrix strategy for r-version: ["4.3", "4.4", "4.5"]

2. After R CMD INSTALL --build ., rename the asset to include the R version and platform before uploading:

   BINARY_RAW=$(ls Hotgenes_*.tgz | head -n 1)
   PKG_VERSION=$(grep '^Version:' DESCRIPTION | awk '{print $2}')
   BINARY_RENAMED="Hotgenes_${PKG_VERSION}_R${{ matrix.r-version }}_macOS-arm64.tgz"
   mv "$BINARY_RAW" "$BINARY_RENAMED"
   echo "BINARY=$BINARY_RENAMED" >> $GITHUB_ENV
   echo "PKG_VERSION=$PKG_VERSION" >> $GITHUB_ENV

3. Handle the GitHub Release creation cleanly across matrix jobs. Recommended approach:

   • Use gh release create only from the 4.4 matrix job (with if: matrix.r-version == '4.4')
   • Use gh release upload for the 4.3 and 4.5 jobs, but ensure the release exists first (add a small retry/wait or use gh release create --skip-if-exists if available, or use gh release create ... || true + gh release upload)
   • A clean alternative: use a single gh release create step with || gh release upload fallback for all matrix jobs

   Pick whichever approach is most reliable and clean.

4. The rest of the workflow steps (checkout, setup-r, setup-r-dependencies, build) remain unchanged per matrix job — just wrapped in the matrix.

The workflow uses secrets.ACTION_TOKEN for both GITHUB_PAT and GH_TOKEN — keep that unchanged.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: que tal con este PR?

Assistant: Aquí está el resumen del PR #21:

---

---

🥜 En pocas palabras

Este PR agrega un script en R para publicar binarios de macOS ARM64 de css-DataFerry en múltiples versiones de R (4.3, 4.4 y 4.5) en el CRAN local de BioMarks. También actualiza la documentación para indicar qué versiones de R tienen binarios disponibles para macOS ARM64.

---

📋 Resumen

Campo	Detalle
Autor	Copilot
Estado	Abierto
Archivos cambiados	2
Líneas añadidas	+51
Líneas eliminadas	0
Reviews	Sin reviews aún
CI / Checks	No disponible
Riesgo	🟢 Bajo — solo añade un nuevo script y documentación, sin modificar lógica existente

Cambios en detalle

1. css-repo/dev_scripts/publish_binaries.R (nuevo archivo)

   • Script para descargar binarios macOS ARM64 desde GitHub Releases del repo css-DataFerry
   • Itera sobre R 4.3, 4.4 y 4.5 construyendo la URL del asset por versión
   • Llama a download_binary_to_biomarks() para registrar cada binario en el CRAN local
   • Usa un guardia if (FALSE) para evitar ejecución accidental al hacer source()

2. css-repo/index.Rmd (modificado)

   • Añade una lista con las versiones de R soportadas (4.3, 4.4, 4.5) para binarios macOS ARM64

---

¿Quieres que…?

1. Revise el PR en detalle buscando posibles mejoras o problemas en el código
2. Analice la seguridad del script (manejo del token, URLs hardcodeadas, etc.)
3. Explique más a fondo la función download_binary_to_biomarks() y cómo encaja este script con el resto del repo

User: es compatible con esto: @pfizer-rd/css-DataFerry/files/BuildSupport/BuildME.R

Assistant: ## Análisis de compatibilidad: PR #21 vs BuildME.R

Hay incompatibilidades importantes entre el nuevo script de PR #21 y el flujo actual en BuildME.R. Aquí el detalle:

---

❌ 1. Naming del asset — incompatible

	Patrón de URL del asset
BuildME.R (actual)	DataFerry_{pkg_version}.tgz
PR #21 (publish_binaries.R)	DataFerry_{pkg_version}_R{rv}_macOS-arm64.tgz

# BuildME.R (línea actual)
asset_url = glue::glue(".../DataFerry_{pkg_version}.tgz")

# publish_binaries.R (PR #21)
asset_url <- paste0(".../DataFerry_", pkg_version, "_R", rv, "_macOS-arm64.tgz")

Si el workflow de GitHub Actions (build-macos-arm64-binary.yml) sigue produciendo assets con el nombre antiguo (DataFerry_X.X.X.tgz), el nuevo script no encontrará los archivos y fallará en la descarga.

---

❌ 2. Versión de R — hardcodeada vs multi-versión

	Versiones de R cubiertas
BuildME.R	Solo "4.4" (hardcodeado)
PR #21	`c("4.3", "4....

This pull request was created from Copilot chat.