Enable publishing updates to non-latest major.minor tags for GitHub action
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
Direzione di ricerca
Inizia tracciando i workflow correnti ci_main, ci_common e ci_branch e identifica quale file JSON di Azure DevOps fornisce la versione. Confronta i relativi trigger esistenti per versione, tag e release con il flusso ci_release proposto e con i branch release/XXX. Il lavoro è completato quando i tag major.minor delle GitHub action che non sono i più recenti possono essere aggiornati senza interrompere la pubblicazione delle attività di Azure DevOps.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
As identified in #223, there is currently a gap in the automated releases for this repo.
Versioning for the GitHub action uses tags in the repo. When someone references devcontainers/ci@vX.Y the workflow runner will look for the vX.Y tag in the repo to fetch.
For the Azure DevOps task, the code is packaged as a VSIX file and submitted to the store. The version of the extension matches the version used in the GitHub release tag. In addition to the extension version, tasks within an extension have their own versions (and there can be multiple versions of a task in sepearate folders in the extension - see here).
So, for Azure DevOps tasks a breaking change can be handled by creating a new task version in a folder alongside the existing task. We can publish updates to either task version in a new extension published from main.
The capability that we want to enable is releasing versions of the GitHub action prior to the latest major.minor version (e.g. new versions of v0.2)
The current versioning process:
- read version from AzDO json file (** which one?)
- set outputs based on the major + minor from json file, and patch from build number
- set patch from output for AzDO
- set tags from outputs for GH
Proposed versioning process:
- new JSON file with major/minor values. Allows for different values per-branch
- read JSON file to set outputs
- rename ci_main to ci_release
- Add params to ci_common to control whether to publish GH and whether to publish AzDO
- ci_release (prev. ci_main) sets publish GH to true, and publish AzDO to true when on release/XXX
- ci_branch sets publish to false for both GH & AzDO
- Update triggers for ci_release to include release/XXX branches
- Lingua principale
- TypeScript
- Stelle
- 496
- Fork
- 102
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di devcontainers/ci
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
devcontainers/ci#446 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
devcontainers/ci#445 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
devcontainers/ci#444 · 1 commento · 3 reazioni ·
-
devcontainers/ci#442 · 1 assegnatario ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
devcontainers/ci#437 ·
Tutte le issue di devcontainers/ci
Issue simili
-
bug(cli): hapi doctor inline-media prints a fabricated B:\ helper-script path in packaged installs Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
Crush Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
catppuccin/catppuccin#3125 ·
-
Add a SECURITY.md Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
ElementsProject/cln-application#167 · 1 commento · 1 reazione ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
Quantco/pnpm-licenses#17 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100