Fix/303 repository improvement #305

AntoninoBonanno · 2024-01-14T22:58:50Z

Chiude: Miglioramento repository #303

Descrizione

Ho aggiunto prettier e migliorato le regole eslint per un codice più pulito e affidabile. (5b1e611)
Adesso prima di effettuare un commit verrà effettuato il 'lint' dei file messi in stage. Così i file, se possibile, verranno automaticamente corretti, altrimenti verrà bloccato il commit mostrando gli errori da correggere in console. (58dd807)
Adesso il formato dei messaggi dei commit verrà analizzato prima di effettuare il push, così lo sviluppatore non può sbagliare il formato del commit. Se il formato è errato verrà visualizzato in console. (6c357c4)
Ho aggiunto semantic-release per il versioning automatico ee creazione di tag/release su GitHub (22098d6)
Ho modificato i workflow per adattarli al semantic-release (75cc845)
Aggiornata la documentazione nel CONTRIBUTING.md (91e1d56)

Semantic release

@astagi non so se hai mai usato questa libreria, l'ho introdotta perchè ho notato degli script sul package.json che mi hanno dato la sensazione che il numero di versione lo si imposta manualmente.

Così invece oltre a facilitare il flusso di deploy, genera automaticamente il numero successivo della versione basandosi sui tipi dei messaggi nei commit. Per tale motivo ti chiedo di fare attenzione ai messaggi nei commit, soprattutto nelle PR di nuovi contributor (eventualmente si fa uno squash con un messaggio dedicato).

Quindi la regola è:

se devo incrementare il numero di versione, quindi è perchè ho modificato file della libreria, uso i tipi fix,feat e BREAKING CHANGE
se non devo modificare il numero di versione posso usare gli altri tipi
- quindi se devo fare fix o feat sulla documentazione bisogna usare docs e magari nello scope indicare se è fix o feat (Esempio docs(fix): fixed button example)

E' descritto meglio nel file CONTRIBUTING.md.

Magari per adesso che siamo in prerelease e non abbiamo un cambiamento di tipo semver sul tag, tutto questo sembra essere inutile, ma sarà molto comodo appena verrà rilasciata la versione stabile.

Se ho configurato tutto bene, il formato del changelog, il nome del tag e la release dovrebbero generarsi come è stato fin ora. Cambia che è tutto automatizzato al push sulla main.

@astagi ti chiedo gentilmente se puoi verificare i workflow che ho creato, dovrebbero funzionare così:

Lint commits: effettua il lint dei messaggi di commit
- Eseguito al push sulla main e nelle PR con destinazione main
Run tests: verifica se la documentazione e la libreria vengono compilate correttamente ed effettua i test
- Eseguito al push sulla main e nelle PR con destinazione main
Publish release: effettua il semantic-release
- Eseguito solo al push sulla main e se Run tests si è concluso correttamente (Verificare che non si azioni nelle PR)
- Se ci sono modifiche (fix,feat e BREAKING CHANGE) cambia il numero di versione in entrambi i progetti, rilascia il pacchetto npm, genera changelog, genera il tag, genera la release su GitHub, effettua un commit con i file aggiornati.
- Se non ci sono modifiche il workflow non fallisce
Update documentation: aggiorna il sito della documentazione
- Eseguito solo al push sulla main e se Publish release si è concluso correttamente (Quindi anche se non ci sono modifiche alla libreria, la documentazione verrà aggiornata)
Slack notification: notifica a slack
- Eseguito solo al push tag (Quindi solo se Publish release ha rilasciato un tag)

Refs: #303

vercel · 2024-01-14T22:58:56Z

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
design-angular-kit	✅ Ready (Inspect)	Visit Preview	Jan 24, 2024 1:18pm

codecov · 2024-01-14T23:01:16Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (7284f5b) 48.96% compared to head (32dad2c) 46.96%.
Report is 34 commits behind head on main.

❗ Current head 32dad2c differs from pull request most recent head 8dec82b. Consider uploading reports for the commit 8dec82b to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #305      +/-   ##
==========================================
- Coverage   48.96%   46.96%   -2.01%     
==========================================
  Files          74       81       +7     
  Lines        1162     1169       +7     
  Branches      220      242      +22     
==========================================
- Hits          569      549      -20     
- Misses        574      596      +22     
- Partials       19       24       +5

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

commitlint.config.js

AntoninoBonanno · 2024-01-14T23:08:55Z

.npmrc

-message="chore(release): %s :tada:"
+registry=https://registry.npmjs.org/
+always-auth=true
+tag=unstable


Quando bisogna rilasciare la versione stabile: rimuovere tag=unstable

AntoninoBonanno · 2024-01-14T23:09:49Z

release.config.js

+  branches: [
+    {
+      name: "main",
+      prerelease: true


Quando bisogna rilasciare la versione stabile: rimuovere prerelease: true

@astagi ho notato che non è possibile non avere una branch di release (qui ne ho configurata una ma solo di prerelease)

semantic-release/semantic-release#2503 (comment)

La soluzione sembrerebbe usare un'altra branch per i rilasci di pre-release

@AntoninoBonanno ho letto tutta la questione, alla fine mi son convinto di aprire una branch prerelease dove direi di attivare le varie action. Quando si lancia una action possiamo decidere se lanciarla su main oppure su prerelease penso che a questo punto semanticrelase riesca a riconoscere il branch e capire cosa rilasciare.

.github/workflows/publish-release.yml

astagi · 2024-01-15T15:45:34Z

Chiude: Miglioramento repository #303

Descrizione

Ho aggiunto prettier e migliorato le regole eslint per un codice più pulito e affidabile. (5b1e611)

Adesso prima di effettuare un commit verrà effettuato il 'lint' dei file messi in stage. Così i file, se possibile, verranno automaticamente corretti, altrimenti verrà bloccato il commit mostrando gli errori da correggere in console. (58dd807)

Adesso il formato dei messaggi dei commit verrà analizzato prima di effettuare il push, così lo sviluppatore non può sbagliare il formato del commit. Se il formato è errato verrà visualizzato in console. (6c357c4)

Ho aggiunto semantic-release per il versioning automatico ee creazione di tag/release su GitHub (22098d6)

Ho modificato i workflow per adattarli al semantic-release (75cc845)

Aggiornata la documentazione nel CONTRIBUTING.md (91e1d56)

Semantic release

@astagi non so se hai mai usato questa libreria, l'ho introdotta perchè ho notato degli script sul package.json che mi hanno dato la sensazione che il numero di versione lo si imposta manualmente.

Così invece oltre a facilitare il flusso di deploy, genera automaticamente il numero successivo della versione basandosi sui tipi dei messaggi nei commit. Per tale motivo ti chiedo di fare attenzione ai messaggi nei commit, soprattutto nelle PR di nuovi contributor (eventualmente si fa uno squash con un messaggio dedicato).

Quindi la regola è:

se devo incrementare il numero di versione, quindi è perchè ho modificato file della libreria, uso i tipi fix,feat e BREAKING CHANGE

se non devo modificare il numero di versione posso usare gli altri tipi

quindi se devo fare fix o feat sulla documentazione bisogna usare docs e magari nello scope indicare se è fix o feat (Esempio docs(fix): fixed button example)

E' descritto meglio nel file CONTRIBUTING.md.

Magari per adesso che siamo in prerelease e non abbiamo un cambiamento di tipo semver sul tag, tutto questo sembra essere inutile, ma sarà molto comodo appena verrà rilasciata la versione stabile.

Se ho configurato tutto bene, il formato del changelog, il nome del tag e la release dovrebbero generarsi come è stato fin ora. Cambia che è tutto automatizzato al push sulla main.

@astagi ti chiedo gentilmente se puoi verificare i workflow che ho creato, dovrebbero funzionare così:

Lint commits: effettua il lint dei messaggi di commit

Eseguito al push sulla main e nelle PR con destinazione main

Run tests: verifica se la documentazione e la libreria vengono compilate correttamente ed effettua i test

Eseguito al push sulla main e nelle PR con destinazione main

Publish release: effettua il semantic-release

Eseguito solo al push sulla main e se Run tests si è concluso correttamente (Verificare che non si azioni nelle PR)

Se ci sono modifiche (fix,feat e BREAKING CHANGE) cambia il numero di versione in entrambi i progetti, rilascia il pacchetto npm, genera changelog, genera il tag, genera la release su GitHub, effettua un commit con i file aggiornati.

Se non ci sono modifiche il workflow non fallisce

Update documentation: aggiorna il sito della documentazione

Eseguito solo al push sulla main e se Publish release si è concluso correttamente (Quindi anche se non ci sono modifiche alla libreria, la documentazione verrà aggiornata)

Slack notification: notifica a slack

Eseguito solo al push tag (Quindi solo se Publish release ha rilasciato un tag)

Gran bel lavoro! La libreria è molto interessante, bisognerebbe capire se possiamo utilizzare un versionamento "custom" come già stiamo facendo su Bootstrap Italia e sui kit, ovvero la major version sarà sulla second cifra invece che sulla prima (da 1.0.0 a 1.1.0 è una major version).. quando faremo Bootstrap Italia 3 allora passeremo alla 2.0.0 e così via.

AntoninoBonanno · 2024-01-15T17:21:36Z

@astagi si certo per ogni tipologia di commit puoi decidere come aggiornare il semver

https://github.com/semantic-release/commit-analyzer?tab=readme-ov-file#releaserules

Puoi configurare tu questa parte?

astagi · 2024-01-15T17:51:09Z

@astagi si certo per ogni tipologia di commit puoi decidere come aggiornale il semver

https://github.com/semantic-release/commit-analyzer?tab=readme-ov-file#releaserules

Puoi configurare tu questa parte?

Perfetto! Ci guardo, grazie mille @AntoninoBonanno!

AntoninoBonanno · 2024-01-15T18:09:34Z

@astagi Credo che potresti usare delle regole in modo che se si usa feat + uno scope deciso da te -> allora solo in questo caso si aggiorna la major. E dovresti disabilitare il fatto che con i breaking changes si aggiorna la major.

Perchè di default funziona così:

fix: un commit di tipo fix risolve un errore nel codice (correlato al PATCH in un
versionamento SemVer).
feat: un commit di tipo feat introduce una nuova funzionalità al codice (correlato al MINOR in un
versionamento SemVer).
BREAKING CHANGE: un commit che contiene in un piè di pagina BREAKING CHANGE:, o aggiunge un ! subito dopo il
tipo/contesto, all’inizio delle sezioni opzionali corpo o piè di pagina, introduce una breaking API change (correlato
al MAJOR in un versionamento SemVer).

// default Angular
{ breaking: true, release: "major" },
{ revert: true, release: "patch" },
{ type: "feat", release: "minor" },
{ type: "fix", release: "patch" },
{ type: "perf", release: "patch" },

astagi · 2024-01-23T22:49:13Z

release.config.js

+      // This will increase the version in the main project without publishing it
+      "@semantic-release/npm",
+      {
+        "npmPublish": false


@AntoninoBonanno perchè abbiamo disattivato la pubblicazione?

Questa è il numero di versione della documentazione. Quindi aggiorna il numero di versione senza rilasciare. Il comando sotto invece pubblica la libreria

github-actions · 2024-01-24T13:41:48Z

🎉 This PR is included in version 0.14.0-prerelease.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

github-actions · 2024-01-25T09:18:50Z

🎉 This PR is included in version 1.0.0-prerelease.1 🎉

The release is available on:

Your semantic-release bot 📦🚀

github-actions · 2024-03-18T11:57:51Z

🎉 This PR is included in version 1.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

AntoninoBonanno added 7 commits January 14, 2024 21:24

build: added prettier

5b1e611

Refs: #303

build: added husky and lint-staged

58dd807

Refs: #303

build: added git commit lint

6c357c4

Refs: #303

build: added semantic-release

22098d6

Refs: #303

ci: update github workflows for semantic release

75cc845

Refs: #303

docs: update contributing instructions

91e1d56

Refs: #303

docs: added semantic-release badge

d9b18ec

AntoninoBonanno added enhancement New feature or request semantic-release labels Jan 14, 2024

AntoninoBonanno requested a review from astagi January 14, 2024 22:58

AntoninoBonanno commented Jan 14, 2024

View reviewed changes

commitlint.config.js Outdated Show resolved Hide resolved

AntoninoBonanno commented Jan 14, 2024

View reviewed changes

.github/workflows/publish-release.yml Outdated Show resolved Hide resolved

AntoninoBonanno assigned astagi Jan 14, 2024

astagi linked an issue Jan 18, 2024 that may be closed by this pull request

Miglioramento repository #303

Closed

4 tasks

ci(fix): run publish release workflow manually

4cc164c

vercel bot deployed to Preview January 22, 2024 18:26 View deployment

astagi reviewed Jan 23, 2024

View reviewed changes

vercel bot deployed to Preview January 24, 2024 09:25 View deployment

ci: use prerelease branch

8dec82b

astagi force-pushed the fix/303-repository-improvement branch from 32dad2c to 8dec82b Compare January 24, 2024 13:16

vercel bot deployed to Preview January 24, 2024 13:18 View deployment

astagi merged commit daea2e3 into main Jan 24, 2024
4 checks passed

github-actions bot added the released on @prerelease label Jan 24, 2024

astagi deleted the fix/303-repository-improvement branch January 29, 2024 13:14

astagi restored the fix/303-repository-improvement branch January 29, 2024 13:14

astagi deleted the fix/303-repository-improvement branch January 29, 2024 13:15

github-actions bot added the released label Mar 18, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix/303 repository improvement #305

Fix/303 repository improvement #305

AntoninoBonanno commented Jan 14, 2024 •

edited

Loading

vercel bot commented Jan 14, 2024 •

edited

Loading

codecov bot commented Jan 14, 2024 •

edited

Loading

AntoninoBonanno Jan 14, 2024

AntoninoBonanno Jan 14, 2024

AntoninoBonanno Jan 15, 2024

astagi Jan 23, 2024

astagi commented Jan 15, 2024

Descrizione

Semantic release

AntoninoBonanno commented Jan 15, 2024 •

edited

Loading

astagi commented Jan 15, 2024 •

edited

Loading

AntoninoBonanno commented Jan 15, 2024 •

edited

Loading

astagi Jan 23, 2024

AntoninoBonanno Jan 24, 2024

github-actions bot commented Jan 24, 2024

github-actions bot commented Jan 25, 2024

github-actions bot commented Mar 18, 2024

Fix/303 repository improvement #305

Fix/303 repository improvement #305

Conversation

AntoninoBonanno commented Jan 14, 2024 • edited Loading

Descrizione

Semantic release

vercel bot commented Jan 14, 2024 • edited Loading

codecov bot commented Jan 14, 2024 • edited Loading

Codecov Report

AntoninoBonanno Jan 14, 2024

Choose a reason for hiding this comment

AntoninoBonanno Jan 14, 2024

Choose a reason for hiding this comment

AntoninoBonanno Jan 15, 2024

Choose a reason for hiding this comment

astagi Jan 23, 2024

Choose a reason for hiding this comment

astagi commented Jan 15, 2024

Descrizione

Semantic release

AntoninoBonanno commented Jan 15, 2024 • edited Loading

astagi commented Jan 15, 2024 • edited Loading

AntoninoBonanno commented Jan 15, 2024 • edited Loading

astagi Jan 23, 2024

Choose a reason for hiding this comment

AntoninoBonanno Jan 24, 2024

Choose a reason for hiding this comment

github-actions bot commented Jan 24, 2024

github-actions bot commented Jan 25, 2024

github-actions bot commented Mar 18, 2024

AntoninoBonanno commented Jan 14, 2024 •

edited

Loading

vercel bot commented Jan 14, 2024 •

edited

Loading

codecov bot commented Jan 14, 2024 •

edited

Loading

AntoninoBonanno commented Jan 15, 2024 •

edited

Loading

astagi commented Jan 15, 2024 •

edited

Loading

AntoninoBonanno commented Jan 15, 2024 •

edited

Loading