loopbackio / loopbackio/loopback.io

Move vendored assets to Git Submodules and `.gitignore` built assets

Ouverte
#2,052 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

ci developer-experience
Langage dominant
HTML
Étoiles
276
Forks
382
Merge moyen
6 h 17 min
PR mergées (30 j)
18

Description

The website has scripts which pulls data from GitHub and NPM:

  • update-blog.sh
    Clones loopbackio/loopback-blog into /blog
  • update-readmes.sh
    Downloads READMEs from GitHub "raw" or NPM Registry into /doc/en/[lb3|lb4|community]/readmes
  • update-lb4-docs.js
    Copies pre-generated markdown API Docs from @loopback/docs into /doc/en/lb4

They pose some issues:

  • Accidental manual editing: Contributors may accidentally contribute changes to these assets, only to be overridden by the CI pipeline.
  • Rate-limitng: Contributors running npm run build -> update-readmes.sh may inadvertently update the local copies with GitHub "rate limit reached" error pages.
  • Unclear provenance: As the .git directory is not preserved, the provenance of where and when exactly the assets were vendored is no clear.
  • Updates are reactive: The assets are only re-vendored when a PR is merged.

Git Submodules solve this problem. Updates would be handled by Renovate instead, which would open PRs.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez par lire update-blog.sh, update-readmes.sh et update-lb4-docs.js, puis examinez comment npm run build les invoque et comment CI gère les assets générés. Définissez les emplacements des sous-modules et les chemins de build qui doivent être ignorés. Le travail est considéré comme terminé lorsque les sources vendorisées ont une provenance Git claire, que les builds ne remplacent plus les copies générées suivies par le contrôle de version et que le build existant du site fonctionne toujours.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
git, github, nodejs, shell
Domaine
build-system, documentation
Type d'issue
Refactorisation
Difficulté
4/5
Temps estimé
3-5 jours
Activité
Calme
Clarté
Plutôt claire
Accessibilité débutants
48/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.