Re-implement and enhance `check-formatting.yml` Github Actions workflow as a Node script
@miorel y travaille déjà.
Depuis le 17/8/2024.
Évaluation
Cette issue n'a pas encore été évaluée.
Description
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.
- Langage dominant
- TypeScript
- Étoiles
- 20
- Forks
- 12
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Préparer son environnement
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de code-chronicles-code/leetcode-curriculum
-
enhancement kotlin
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
-
good first issue tests
Difficulté 1/5 1-3 heures Accessibilité débutants 82/100
-
Add tests for `swap` utilityOuvertegood first issue tests
Difficulté 2/5 1-3 heures Accessibilité débutants 64/100
-
good first issue tests
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
-
bug
Difficulté 4/5 3-5 jours Accessibilité débutants 30/100
code-chronicles-code/leetcode-curriculum#418 · 1 commentaire ·
Toutes les issues de code-chronicles-code/leetcode-curriculum
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
openedx/frontend-app-authoring#3274 ·
Les mainteneurs répondent en général sous 1 jour
-
🎙️ task - fix(deployer): deploy --env prep runs deploy:dev where the repo declares deploy:prepOuverte
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
-
area/documentation status/need-triage
Difficulté 1/5 Moins d'une heure Accessibilité débutants 95/100
google-gemini/gemini-cli#29548 ·
Les mainteneurs répondent en général sous 1 jour
-
sdk-typescript vector-store
Difficulté 2/5 Une demi-journée Accessibilité débutants 82/100
mem0ai/mem0#7495 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
Les mainteneurs répondent en général sous 1 jour