Re-implement and enhance `check-formatting.yml` Github Actions workflow as a Node script
@miorel arbeitet bereits daran.
Seit 17.8.2024.
Bewertung
Dieses Issue wurde noch nicht bewertet.
Beschreibung
The workflow introduced in #225 is currently powered by a shell command, namely yarn format && git status --porcelain piped through some not very easy to maintain inline Perl.
Let's rewrite this as a Node script that's more maintainable. This is also an opportunity to address the other TODO in the workflow file, and have it output a summary as described at https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#adding-a-job-summary
The general behavior of the workflow should be:
- Run
yarn formatto rewrite any files that are not correctly formatted. This part can still happen outside Node, so for example the command we run becomes something likeyarn format && node some-script.js. - The script basically replaces the
git status --porcelainpart and the subsequent Perl expression it's piped into. The script should therefore still rungit status --porcelainfrom within Node and capture the output. - For each line in the output of
git status --porcelain, the script should remove the first 3 characters (see explanation of the format at https://git-scm.com/docs/git-status#_porcelain_format_version_1 to understand why) to get only the filename. It should then output an error message (using the format described at https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-error-message) to indicate that the file in question doesn't respect the repository's formatting rules. - For bonus points (this part can be done as a separate PR) output a markdown summary at the end.
- If there were any files that were improperly formatted, the script should exit with a non-zero exit code so that the check fails and draws the attention of the author and reviewers.
- Vorherrschende Sprache
- TypeScript
- Sterne
- 20
- Forks
- 12
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus code-chronicles-code/leetcode-curriculum
-
enhancement kotlin
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
-
good first issue tests
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 82/100
-
Add tests for `swap` utilityEvtl. wieder frei Ein Pull Request dazu wurde ohne Merge geschlossen. Offengood first issue tests
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 64/100
-
good first issue tests
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
-
bug
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 30/100
code-chronicles-code/leetcode-curriculum#418 · 1 Kommentar ·
Alle Issues in code-chronicles-code/leetcode-curriculum
Ähnliche Issues
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 70/100
lingdojo/kana-dojo#32590 · 1 Kommentar · 5 Reaktionen ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug p2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
bastani-inc/atomic#3703 ·
Maintainer antworten meist innerhalb von 1 Tag
-
backend bug difficulty: medium priority: medium reliability
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
trustflow-protocol/trustflow-backend#730 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
firecrawl/firecrawl-mcp-server#548 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
Maintainer antworten meist innerhalb von 1 Tag