La delivery del software è un momento molto particolare poichè dobbiamo prestare attenzione a cosa rilasciamo. Proprio per questo, è importante che impostiamo quante più branch policy possibili per automatizzare al massimo il processo e limitare i possibili danni che potremmo fare intervenendo in modo alternativo a quanto previsto.
Supponendo di dover lavorare con una branching strategy basata sullo standard GitFlow, per esempio, potrebbe venir comodo limitare gli accessi al branch principale solamente a pull request che arrivano dai branch di release. Poichè non esiste niente di built-in in GitHub, ci possiamo costruire un workflow custom.
name: Validate branch name on: pull_request: branches: - main jobs: validate-merge-ref: name: Validate merge ref on main runs-on: ubuntu-latest steps: - name: Validate head ref if: ${{ !startsWith(github.event.pull_request.head.ref, 'release') }} run: exit 1
Il workflow di esempio viene eseguito sempre ad ogni creazione o update di una pull request che fa target al branch main, ovvero il principale di cui vogliamo tracciare le release fatte e pronte per la messa in produzione.
Tra gli step ne abbiamo solo uno, che viene eseguito solo nel caso in cui il branch da cui è stata originata la PR non sia release. In caso lo sia, lo step non viene eseguito e il workflow termina con successo senza aver eseguito di fatto niente. Al contrario, lo step lancia un exit code diverso da zero, che produce automaticamente un errore e fa terminare il processo.
Se uniamo questo workflow alle branch policy di GitHub, possiamo facilmente controllare tutte le pull request che vengono eseguite sul branch main e impedire che venga fatto il merge di codice che arriva da branch che non corrispondono al processo definito.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Visualizzare le change sul plan di Terraform tramite le GitHub Actions
Eseguire una query su SQL Azure tramite un workflow di GitHub
Usare una container image come runner di GitHub Actions
Utilizzare il trigger SQL con le Azure Function
Eseguire le GitHub Actions offline
Gestire errori funzionali tramite exception in ASP.NET Core Web API
Sostituire la GitHub Action di login su private registry
Generare token per autenicarsi sulle API di GitHub
Determinare lo stato di un pod in Kubernetes
Evitare (o ridurre) il repo-jacking sulle GitHub Actions
Utilizzare la libreria Benchmark.NET per misurare le performance
Assegnare un valore di default a un parametro di una lambda in C#
I più letti di oggi
- Utilizzare WebAssembly con .NET, ovunque
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
- Utilizzare il trigger SQL con le Azure Function
- Ottimizzazione dei block template in Angular 17
- Disabilitare automaticamente un workflow di GitHub (parte 2)