Improve package download flow
Los mantenedores suelen responder en 6 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- gitlab, go
- Área
- backend, infrastructure
Línea de trabajo
Comienza rastreando el flujo existente de descarga de paquetes, análisis, guardado del archivo y carga descrito en el issue, así como los cambios de #739. Define un diseño que haga que el archivo analizado sea el mismo que se guarda y se carga, y decide cómo se gestionan los paquetes de Packagist alojados en GitLab o si se requiere el comportamiento heredado.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Since #739 has been merged, we now have the ability to redownload and save the package archive (**) after analysis.
It would be ideal if the downloaded/saved archive is the same one that's used for analysis
Some possible ways to achieve this:
- Downloading the archive first in the worker container, then copying it into the static and dynamic sandboxes. These then do analysis as if on a local package.
- Have the static analysis sandbox double as the 'package downloader' container, then copy the downloaded files back to the host and into the dynamic analysis container, as well as uploading them to the bucket
- Have a separate 'downloader' container whose sole job is to download everything, and pass it to the other containers like in option 1.
** One caveat with all this is that Packagist packages hosted on GitLab don't offer direct package archive download URLs. We will need to figure out how to support this case (or possibly fall back to legacy behaviour).
- Lenguaje dominante
- Go
- Estrellas
- 925
- Forks
- 75
- Merge medio
- 4 d 2 h
- PR fusionados (30 d)
- 3
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin 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 ossf/package-analysis
-
Python execute phase aborts with error_analysis when the package closes stdout (MCP stdio servers)Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 78/100
ossf/package-analysis#1200 ·
Los mantenedores suelen responder en 6 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
ossf/package-analysis#1192 ·
Los mantenedores suelen responder en 6 días
-
OpenSSF Documentation UpdatesAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
ossf/package-analysis#1125 ·
Los mantenedores suelen responder en 6 días
-
4gbAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 5/100
ossf/package-analysis#1123 ·
Los mantenedores suelen responder en 6 días
-
>4 gbAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 10/100
ossf/package-analysis#1122 ·
Los mantenedores suelen responder en 6 días
Todos los issues de ossf/package-analysis
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
evener-transcript-v2-upgrade tool still scans transcript files through bufio's 4 KiB default bufferAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 78/100
prime-radiant-inc/evener#6370 ·
Los mantenedores suelen responder en 1 día
-
ManageSieve proxy: a backend's NO/BYE greeting is skipped as a capability line and reported as EOFAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Mend: dependency security vulnerability
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Mend: dependency security vulnerability
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
ManageIQ/manageiq-pods#1476 ·
Los mantenedores suelen responder en 1 día