Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Improve build strategy

Aperta
#102 12 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github, python

Direzione di ricerca

The issue names no source files or tests. Start by reading the repository’s build and publishing workflows to find where generated output is written and how it is published. Compare GitHub Releases and GitHub Pages for storing build results without changing source files; done means publishing avoids generated build diffs in source repositories while retaining access to build results.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

The current build strategy results in the creation of a build/ directory at the root of each BBlocks repository.
When working as single-dev on a BBlock, its not too bad because the updates are relatively "fresh" and linear.

However, this becomes quickly impossible to manage with multiple devs, forks, and PRs. Each update, however minimal they may be, yields massive build diffs just because of the regenerated datetimes, commit hash, reported test results, etc.

For example:
https://github.com/crim-ca/bblocks-process-profiles/compare/master...GeoLabs%3Abblocks-process-profiles%3Amaster
Only adding a script, an example and README for it, leads to 757 changed files with 78,911 additions and 73,989 deletions (out of the 3 files of actual interest).

There is a lot of noise, and there is no way developers will be able to create reviews or find comments reviews across all this. Also, because of all those changes, I cannot even easily sync forks due to merge conflicts. I have to do multiple rebase / force push hacks, which increases chances of devs doing mistakes when collaborating.

The publishing strategy must be redesigned, either using GitHub releases or GitHub pages to store those build results, without impacting the source.

Lingua principale
Python
Stelle
1
Fork
6
Merge medio
23h 43m
PR unite (30g)
7

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di opengeospatial/bblocks-postprocess

Tutte le issue di opengeospatial/bblocks-postprocess

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.