[pushmsix] Move app configuration out of init_worker.sh
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
Línea de trabajo
Comienza leyendo init_worker.sh y revisando los patrones de configuración existentes en beetmover e iscript. Compara las opciones task-payload y dedicated-configuration-file con los flujos de trabajo de despliegue y operación, y confirma después que el enfoque elegido mantiene la configuración específica de la aplicación fuera de init_worker.sh, preservando al mismo tiempo el comportamiento actual.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
We currently manage app-specific settings, such as RELEASE_ROLLOUT_PERCENTAGE, BETA_APPLICATION_ID, and RELEASE_APPLICATION_ID, directly within the init_worker.sh file. As we introduce new applications, we continue adding more entries, deviating from the purpose of this file.
We should consider a different approach for handling these settings. Potential solutions include:
-
From Task Payload:
Pass application-specific configurations through the task payload, keeping the logic inside pushmsix simpler, and making the requesting app more explicit on what's being pushed. -
Constants/Configuration File:
Store all app-specific constants in a dedicated configuration file (similar to existing patterns in beetmover, iscript, etc). This file would serve as a centralized reference point, making updates and additions easier.
Open Questions:
- Which approach integrates best with our existing deployment and operational workflows?
- Are there additional options/strategies for handling these settings?
- 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
-
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 ·
-
scope: Refactor dockerhub scope Abiertoenhancement good first issue
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
Todos los issues de mozilla-releng/scriptworker-scripts
Issues similares
-
agent-ready documentation needs-triage
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
-
documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 91/100
-
workflow-status page template still says reusable workflows are "triggered only by workflow_call:" Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 92/100
-
Add https://search.jeremyh.xyz/ Abiertoinstance instance add
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
searxng/searx-instances#939 · 1 comentario ·
-
area-deployment area-integrations triage:bot-seen
Dificultad 2/5 Medio día Aptitud para principiantes 86/100