johanleroy
f96b36c548
Avec un NPM_TOKEN expiré, les trois workflows de release sont ressortis « réussis » alors qu'aucune release n'avait été créée et qu'aucun asset n'était attaché : l'attache était en continue-on-error et le script sortait en 0 quand l'API refusait le token. Diagnostiquer a demandé de comparer les assets de releases pour comprendre ce que les logs auraient dit tout de suite. Désormais : token ABSENT (fork, run sans secret) reste un cas légitime qui sort proprement, mais un token PRÉSENT et refusé, ou un upload d'asset en échec, fait échouer le job avec un message qui nomme les portées attendues. Les artefacts du run sont uploadés AVANT cette étape, donc un job rouge ne perd aucun binaire. L'attache du VSIX passe au même script partagé : elle dupliquait la logique, avec le même angle mort.
60 lines
2.7 KiB
YAML
60 lines
2.7 KiB
YAML
# Packaging du VSIX de l'extension VS Code, déclenché UNIQUEMENT par un tag vscode-vX.Y.Z
|
|
# (séparé de la release du daemon, qui écoute les tags v*). Le .vsix est exposé en artefact du run
|
|
# (toujours) et, en best-effort, attaché à la release Gitea correspondante.
|
|
name: VSCode Release
|
|
|
|
on:
|
|
push:
|
|
tags: ['vscode-v*']
|
|
|
|
permissions:
|
|
contents: write
|
|
|
|
jobs:
|
|
package:
|
|
name: Package VSIX
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
- uses: actions/setup-node@v4
|
|
with:
|
|
node-version: 22
|
|
cache: npm
|
|
- run: npm ci
|
|
# Garde-fou : le tag (sans "vscode-v") doit correspondre à la version du manifeste de l'extension.
|
|
- name: Verify tag matches extension version
|
|
run: |
|
|
pkg=$(node -p "require('./packages/vscode/package.json').version")
|
|
tag="${GITHUB_REF_NAME#vscode-v}"
|
|
if [ "$pkg" != "$tag" ]; then
|
|
echo "ERREUR: tag '$tag' != version extension '$pkg'"
|
|
exit 1
|
|
fi
|
|
echo "OK: tag $tag == version $pkg"
|
|
# Build du shared puis bundle esbuild de l'extension (typecheck inclus), puis packaging VSIX.
|
|
# --no-dependencies : tout est bundlé dans dist/extension.js → pas de node_modules dans le VSIX.
|
|
- name: Build & package
|
|
run: |
|
|
npm run build:vscode
|
|
version=$(node -p "require('./packages/vscode/package.json').version")
|
|
cd packages/vscode
|
|
npx --yes @vscode/vsce package --no-dependencies -o "git-arboretum-${version}.vsix"
|
|
# Artefact du run : canal de distribution fiable, indépendant de l'API release.
|
|
# upload-artifact@v3 : Gitea Actions ne supporte pas @v4 (@actions/artifact v2+).
|
|
- uses: actions/upload-artifact@v3
|
|
with:
|
|
name: vsix
|
|
path: packages/vscode/*.vsix
|
|
# Attache le VSIX à la release Gitea du tag (créée si absente), via le script partagé avec la
|
|
# release desktop : la logique était dupliquée, avec le même angle mort. Réutilise le secret
|
|
# NPM_TOKEN (même token Gitea que la publication du daemon), qui doit porter write:repository en
|
|
# plus de write:package. Sans token du tout, le script sort proprement ; avec un token REFUSÉ, il
|
|
# échoue, pour que l'anomalie soit visible (le VSIX reste dans les artefacts du run).
|
|
- name: Attach VSIX to Gitea release
|
|
env:
|
|
RELEASE_TOKEN: ${{ secrets.NPM_TOKEN }}
|
|
run: |
|
|
version=$(node -p "require('./packages/vscode/package.json').version")
|
|
bash .gitea/scripts/attach-release-assets.sh "${GITHUB_REF_NAME}" "Arboretum VSCode ${version}" \
|
|
"packages/vscode/git-arboretum-${version}.vsix"
|