Provide build artifacts
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 28/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- perl
- Área
- build-system, ci-cd, release
Línea de trabajo
Empieza leyendo la discusión #1304 y la configuración de Travis CI y Dist::Zilla del repositorio, que son los puntos de entrada indicados en el issue. Compara las propuestas de compilación de release-artifact y default-branch; se considera terminado cuando exista una forma acordada y probada de publicar artefactos precompilados utilizables sin requerir todo el entorno de autoría.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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).
- Lenguaje dominante
- Perl
- Estrellas
- 736
- Forks
- 217
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de RexOps/Rex
-
is_redhat() misses Rocky/Alma/CentOS Stream/Oracle Linux lsb_release IDs -> pkg dies "OS/Provider not supported"Posiblemente ocupada @stantheman0128 la tomó hace 20 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
bug
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
-
triage needed
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
bug
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
-
triage needed
Dificultad 3/5 1-2 días Aptitud para principiantes 42/100
Todos los issues de RexOps/Rex
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
libwww-perl/URI#211 ·
-
Type: Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
inverse-inc/packetfence#9549 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 80/100
jimsalterjrs/sanoid#1116 · 1 reacción ·