[meta] refactor scripts to stop importing scriptworker, start importing scriptworker_client
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 30/100
Línea de trabajo
Comienza localizando los scripts que importan scriptworker y compara sus puntos de entrada de línea de comandos con scriptworker_client. Lee la página wiki Testing iscript y sus indicaciones sobre create_test_workdir para la ejecución independiente. Se considera terminado cuando los scripts ya no dependen de los objetos de contexto de scriptworker, manteniendo la API de línea de comandos.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Part of the rationale of having scriptworker call a script from the commandline, rather than import a python module and call a function, was to make the script independent of scriptworker. In theory this would:
- let us upgrade scriptworker without affecting scripts, as long as that commandline api stayed consistent,
- allow us to test scripts standalone, rather than requiring the worker,
- allow for a mixture of languages and python versions
(3) is currently no longer an issue. We've standardized on python 3. However, we still have the option of supporting other languages, especially if some other team wants to start using scriptworkers.
(2) has been theoretical, and still has some issues with user friendliness and discoverability. The testing iscript wiki page shows it's possible to test a script without scriptworker, especially when using the create_test_workdir script from scriptworker to populate the work_dir with a known task's task.json and CoT upstreamArtifacts.
The main thing we're solving here is (1). Because many scripts import scriptworker, upgrading scriptworker may still break those scripts, even if the commandline api stays consistent. Let's import scriptworker_client instead.
Doing so isn't just a simple drop-in replacement, however. scriptworker_client removes the usage of context objects, so this may be a sizeable patch set per script. But once we do this, we'll once more be able to upgrade scriptworker without fear of breaking the script, and we will be able to make all script-related changes in this repo rather than across two repos. (And the vocal opponents to the context objects will be appeased. :)
- Lenguaje dominante
- Python
- Estrellas
- 16
- Forks
- 38
- Merge medio
- 1 d 7 h
- PR fusionados (30 d)
- 14
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
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 mozilla-releng/scriptworker-scripts
-
Dependency Dashboard Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 15/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
-
treescript
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
mozilla-releng/scriptworker-scripts#1055 · 2 comentarios ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 32/100
mozilla-releng/scriptworker-scripts#994 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
mozilla-releng/scriptworker-scripts#980 · 1 comentario ·
Todos los issues de mozilla-releng/scriptworker-scripts
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
stephrobert/dsoxlab#238 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
sublimehq/package_control#1780 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
nwg-piotr/nwg-displays#145 ·