Enforce unique CloudFormation stack names
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- aws, typescript
- Área
- devops
Línea de trabajo
Start by finding where the reusable workflows in apify/workflows construct or accept CloudFormation stack names before deployment, and where a validation step could be inserted (likely a workflow step or a script invoked by it). Note the open design questions in the issue (environment naming scheme, legacy-stack opt-out, name->account mapping) — a decision from a maintainer is needed before implementation. Done looks like: new stacks are rejected unless the name is prefixed with the deploying repo and is unique in the repository, while legacy names remain deployable via an opt-out.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
NOTE: this could be a good first task for a new DevOps engineer.
To prevent issues with overriding CloudFormation stacks because of a naming conflict, we need to ensure that the CloudFormation stacks have unique names.
This would be hard to enforce directly across the whole GitHub organizations, but we can split it into two parts:
- make sure that the stack names are prefixed with the repo that is trying to deploy them
- make sure that the stack names are unique in the repository
We could even make sure that the stack names contain the environment that they're being deployed to, and that they're being deployed to the right environment according to the name.
So there would be stack names like:
apify-core-org-s3-bucketsapify-web-member-iam-roles
TBD: should the environments be called org and member, or org, prod and staging?
Unfortunately, CloudFormation doesn't let you rename existing stacks, so we'll have to have some option to opt-out of these names for legacy stacks. We should not allow new stacks to be created with the wrong names, though. Maybe, if the legacy stack name is in the wrong format and the repo and account can't be inferred automatically, we could even have a mapping of stack name -> repo & AWS account that would verify that the stacks are being deployed to the correct account.
- Lenguaje dominante
- TypeScript
- Estrellas
- 15
- Forks
- 7
- Merge medio
- 1 d 16 h
- PR fusionados (30 d)
- 5
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
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 apify/workflows
-
Dependency DashboardAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 12/100
Todos los issues de apify/workflows
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
juice-shop/juice-shop#3686 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
dsh-market/dsh-market#877 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
ScottKirvan/GOMAC#61 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
stellar/stellar-dev-skill#151 ·
Los mantenedores suelen responder en 1 día