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

Provide build artifacts

Aperta
  • Qualcosa non va?
#1,390 0 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
28/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
perl
Ambito
build-system, ci-cd, release

Direzione di ricerca

Inizia leggendo la discussione #1304 e la configurazione di Travis CI e Dist::Zilla del repository, che sono i punti di ingresso indicati nell’issue. Confronta le proposte di build release-artifact e default-branch; il lavoro è completato quando esiste un modo concordato e testato per pubblicare artefatti precompilati utilizzabili senza richiedere l’intero ambiente di authoring.

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

Descrizione

User story

As a package maintainer,
I would like to use pre-built artifacts for packaging,
so I can avoid pulling in the whole authoring environment as build dependencies.

Describe the solution you'd like

The idea is to save the build results for each successfully tested commit of the default git branch, and ask Travis CI to publish them somewhere (e.g. in a separate branch, or repo). That way package maintainers may decide between using these pre-built "git builds" as installation source, packaging the whole build system, or anything in between (e.g. drop the author plugins, and only package the rest).

  • idea 1: save build directory (or tarball) of tagged releases as standard GitHub Releases
  • idea 2: save build directory (or tarball) of each successfully built commit from the default git branch ("bleeding edge builds")

Describe alternatives you've considered

See the discussion #1304. That is originally about implementing the patching logic which can be executed during package build time, but also touches using vendor-specific dist.ini files, or just maintaining the diff for them (ideally the discussion could have taken place in an issue first, but I don't want to duplicate everything by copying text over here now).

I'm also not comfortable bringing in vendor-specific packaging details into the project scope, mostly because if a vendor would like to build Rex differently than upstream, that is great, but I think it still primarily is a decision and concern of the vendor. That may be rephrased as: "we supply how we intend Rex to be built; that's completely fine if you have a different opinion, and feel free to build it differently, but that's your choice".

Additional context

The build process of Rex relies on various Dist::Zilla plugins. Some of it is important only for authors (people who modify Rex itself), and strictly speaking only the rest are important for end-users (people who want to build and install Rex). Furthermore, there's a distinction between tagged releases and building from the default git branch.

OS packages for tagged releases can use pre-built sources e.g. from CPAN (while it would also be nice to upload these tarballs as GitHub Releases as well). But if you'd like write a package that builds Rex from source (like a specific commit or branch), the whole list of build dependencies has to be pulled in. That might impose a prohibitive cost on the packaging side, with relatively low returns in exchange (e.g. using Test::PerlTidy to ensure that the source code is tidy: it's mostly important for authors to keep the code style consistent, but less important for end-users who only want to run Rex).

Lingua principale
Perl
Stelle
736
Fork
217
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

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 RexOps/Rex

Tutte le issue di RexOps/Rex

Issue simili

Altre issue su Perl

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.