Configuración del servidor
Esta página explica cómo configurar el comando atlantis server.
La configuración de atlantis server puede especificarse mediante flags de línea de comandos, variables de entorno, un archivo de configuración o una mezcla de los tres.
Variables de entorno
Todos los flags pueden especificarse como variables de entorno.
- Tome el nombre del flag, p. ej.
--gh-user - Ignore el primer
--=>gh-user - Convierta los
-en_=>gh_user - Ponga todas las letras en mayúsculas =>
GH_USER - Añada el prefijo
ATLANTIS_=>ATLANTIS_GH_USER
NOTE
Para establecer un flag booleano use true o false como valor.
NOTE
El flag --atlantis-url se establece mediante la variable de entorno ATLANTIS_ATLANTIS_URL NO ATLANTIS_URL.
Archivo de configuración
Todos los flags también pueden especificarse mediante un archivo de configuración YAML.
Para usar un archivo de configuración YAML, ejecute atlantis server --config /path/to/config.yaml.
Las claves de su archivo de configuración deben ser las mismas que los nombres de los flags, p. ej.
gh-token: ...
log-level: ...WARNING
El archivo de configuración que pasa a --config es diferente del archivo --repo-config. El archivo de configuración de --config solo se usa como una forma alternativa de establecer flags de atlantis server.
Precedencia
Los valores se eligen en este orden:
- Flags
- Variables de entorno
- Archivo de configuración
Flags
--allow-commands v0.27.0+
atlantis server --allow-commands=version,plan,apply,unlock,approve_policies,cancel
# or
ATLANTIS_ALLOW_COMMANDS='version,plan,apply,unlock,approve_policies,cancel'Lista de comandos permitidos para ejecutarse en el servidor Atlantis, por defecto es version,plan,apply,unlock,approve_policies,cancel
Notas:
- Acepta una lista separada por comas, p. ej.
command1,command2. version,plan,apply,unlock,approve_policies,cancel,import,state,policy_checkyallestán disponibles.policy_checkes un comando interno que se ejecuta automáticamente después deplancuando policy checking está habilitado. Debe incluirse explícitamente en la allowlist al usar--gh-team-allowlist.alles una palabra clave especial que permite todos los comandos. Si pasaallentonces todos los demás comandos serán ignorados.
--allow-draft-prs v0.13.0
atlantis server --allow-draft-prs
# or
ATLANTIS_ALLOW_DRAFT_PRS=trueResponder a pull requests de draft prs. El valor predeterminado es false.
--allow-fork-prs v0.3.1+
atlantis server --allow-fork-prs
# or
ATLANTIS_ALLOW_FORK_PRS=trueResponder a pull requests desde forks. El valor predeterminado es false.
SECURITY WARNING
Potencialmente peligroso de habilitar porque si atacantes pueden crear un pull request a su repo entonces pueden hacer que Atlantis ejecute código arbitrario. Esto puede ocurrir porque Atlantis ejecutará automáticamente terraform plan que puede ejecutar código arbitrario si recibe una configuración Terraform maliciosa.
--api-secret v0.22.2+
atlantis server --api-secret="secret"
# or (recommended)
ATLANTIS_API_SECRET="secret"Secreto requerido usado para validar solicitudes hechas a los endpoints /api/*.
--atlantis-url v0.1.3+
atlantis server --atlantis-url="https://my-domain.com:9090/basepath"
# or
ATLANTIS_ATLANTIS_URL=https://my-domain.com:9090/basepathEspecifique la URL desde la que Atlantis es accesible. Se usa en la UI de Atlantis y en enlaces desde comentarios de pull request. El valor predeterminado es http://$(hostname):$port donde $port proviene del flag --port. Soporta un basepath si está alojando Atlantis bajo una ruta.
Notas:
- Si se usa un balanceador de carga con un puerto no http/https (no el definido en el flag
--port), actualice la URL para incluir el puerto como en el ejemplo anterior. - Esta URL se usa como el enlace
detailsjunto a cada job de atlantis para ver los logs del job.
--autodiscover-mode v0.27.0+
atlantis server --autodiscover-mode="<auto|enabled|disabled>"
# or
ATLANTIS_AUTODISCOVER_MODE="<auto|enabled|disabled>"Establece el modo auto discover, el predeterminado es auto. Cuando se establece en auto, los proyectos en un repo serán descubiertos por Atlantis cuando no haya proyectos configurados en la configuración del repo. Si uno o más proyectos están definidos en la configuración del repo, entonces el auto discovery se deshabilitará completamente.
Cuando se establece en enabled los proyectos serán descubiertos incondicionalmente. Si un proyecto descubierto automáticamente ya está definido en la sección projects de la configuración del repo, el proyecto de la configuración del repo tendrá precedencia sobre el proyecto descubierto automáticamente.
Cuando se establece en disabled los proyectos nunca serán descubiertos, incluso si no hay proyectos configurados en la configuración del repo.
--automerge v0.17.0
atlantis server --automerge
# or
ATLANTIS_AUTOMERGE=trueFusionar automáticamente pull requests después de que todos los plans se hayan aplicado correctamente. El valor predeterminado es false. Vea Automerging para más detalles.
--automerge-method
atlantis server --automerge-method="squash"
# or
ATLANTIS_AUTOMERGE_METHOD="squash"Método de merge predeterminado para usar al hacer automerging de pull requests. Los valores válidos son merge, rebase, y squash. Cuando no se establece, se usa el método de merge predeterminado del proveedor VCS. Esto puede sobrescribirse por comando con el flag de comentario --auto-merge-method. Actualmente solo está implementado para GitHub.
--autoplan-file-list v0.15.0+
# NOTE: Use single quotes to avoid shell expansion of *.
atlantis server --autoplan-file-list='**/*.tf,project1/*.pkr.hcl'
# or
ATLANTIS_AUTOPLAN_FILE_LIST='**/*.tf,project1/*.pkr.hcl'Lista de patrones de archivos que Atlantis usará para comprobar si un directorio contiene archivos modificados que deben activar project planning.
Notas:
- Acepta una lista separada por comas, p. ej.
pattern1,pattern2. - Los patrones usan la sintaxis
.dockerignore - La lista de patrones de archivos será usada tanto por plans ejecutados automáticamente como manualmente.
- Cuando no se establece, el valor predeterminado son todos los archivos
.tf,.tf.json,.tfvars,.tfvars.json,.tofu,.tofu.json,terragrunt.hcly.terraform.lock.hcl(--autoplan-file-list='**/*.tf,**/*.tf.json,**/*.tfvars,**/*.tfvars.json,**/*.tofu,**/*.tofu.json,**/terragrunt.hcl,**/.terraform.lock.hcl'). - Establecer
--autoplan-file-listsobrescribirá los valores predeterminados. Debe agregar**/*.tfy otros valores predeterminados si desea incluirlos. - El valor predeterminado es global (no distribution-aware). Tanto las instalaciones de Terraform como de OpenTofu coincidirán con cambios en
.tofu. Si no usa OpenTofu, puede sobrescribir el valor predeterminado para excluir patrones.tofu. - Un Workflow personalizado que use autoplan
when_modifiedignorará este valor.
Ejemplos:
- Autoplan cuando se modifica cualquier archivo
*.tfo*.tfvars.--autoplan-file-list='**/*.tf,**/*.tfvars'
- Autoplan cuando se modifica cualquier archivo
*.tfexcepto en el directorioproject2/--autoplan-file-list='**/*.tf,!project2'
- Autoplan cuando se modifica cualquier archivo
*.tfo archivos.ymlen una subcarpeta deproject1.--autoplan-file-list='**/*.tf,project1/**/*.yml'
NOTE
De forma predeterminada, los cambios en módulos no activarán autoplanning. Vea los flags a continuación.
--autoplan-modules v0.26.0+
atlantis server --autoplan-modules
# or
ATLANTIS_AUTOPLAN_MODULES=trueEl valor predeterminado es false. Cuando se establece en true, Atlantis rastreará los módulos locales de los proyectos incluidos. Los proyectos incluidos son proyectos con archivos incluidos por --autoplan-file-list. Después del rastreo, Atlantis hará plan de cualquier proyecto que incluya un módulo modificado. Esto equivale a establecer --autoplan-modules-from-projects al valor de --autoplan-file-list. Vea abajo.
NOTE
La indexación de dependencias de módulos usa inspección de configuración de Terraform y puede no soportar completamente archivos .tofu / .tofu.json. Las llamadas a módulos definidas solo en archivos .tofu o directorios de módulos compartidos que contienen solo archivos .tofu pueden no ser rastreadas. El autoplanning directo por cambio de archivo para proyectos .tofu funciona independientemente. Use patrones explícitos autoplan.when_modified como solución alternativa. Vea OpenTofu .tofu file support para detalles.
--autoplan-modules-from-projects v0.26.0+
atlantis server --autoplan-modules-from-projects='**/init.tf'
# or
ATLANTIS_AUTOPLAN_MODULES_FROM_PROJECTS='**/init.tf'Habilita auto-planing de proyectos cuando una dependencia de módulo en el mismo repositorio ha cambiado. Esta es una lista de patrones de archivos como autoplan-file-list.
Estos patrones seleccionan proyectos para indexar en función de los archivos coincidentes. El índice mapea módulos a los proyectos que dependen de ellos, incluyendo proyectos que incluyen el módulo mediante otros módulos. Cuando cambia un archivo de módulo que coincide con autoplan-file-list, todos los proyectos indexados tendrán plan.
El valor predeterminado actual es "" (deshabilitado).
Ejemplos:
**/*.tf- indexará todos los proyectos que tengan un archivo.tfen su directorio, y les hará plan cada vez que una dependencia de módulo dentro del repo haya cambiado.**/*.tf,!foo,!bar- indexará todos los proyectos que contengan.tfexceptofooybary les hará plan cada vez que una dependencia de módulo dentro del repo haya cambiado. Esto permite que los proyectos opten por no usar auto-planning cuando una dependencia de módulo cambia.
NOTE
Los módulos que no sean seleccionados por autoplan-file-list no serán indexados y no se hará plan de los proyectos dependientes. Este flag permite seleccionar los proyectos a indexar, pero el disparador para un plan debe ser un archivo en autoplan-file-list.
NOTE
Este flag sobrescribe --autoplan-modules. Si desea deshabilitar auto-planning de módulos, establezca este flag en una cadena vacía, y establezca --autoplan-modules en false.
--azuredevops-hostname v0.9.0+
atlantis server --azuredevops-hostname="dev.azure.com"
# or
ATLANTIS_AZUREDEVOPS_HOSTNAME="dev.azure.com"Hostname de Azure DevOps para soportar instancias cloud y self-hosted. El valor predeterminado es dev.azure.com.
COMPATIBILITY WARNING
Si le afecta este cambio docs o este issue ambos Service Hooks (v1 y v2) convertirán el nombre de la organización de AD a minúsculas: Ejemplos: https://dev.azure.com/MYCompany/ & https://mycompany.visualstudio.com/ se convertirán en mycompanyhttps://dev.azure.com/MYCOMPANY/ & https://myCOMPANY.visualstudio.com/ se convertirán en mycompany
Este cambio se aplicará a partir de la versión v0.35.0
¿Qué hacer si tiene plans pendientes que fueron generados con una versión anterior? Ejecutar un atlantis unlock desde v0.35.0 en sus PR actuales ignorará los archivos en la carpeta MYCompany. En el siguiente atlantis plan se usará la carpeta mycompany y se generará todo en el nuevo nombre de carpeta
--azuredevops-token v0.9.0+
atlantis server --azuredevops-token="RandomStringProducedByAzureDevOps"
# or (recommended)
ATLANTIS_AZUREDEVOPS_TOKEN="RandomStringProducedByAzureDevOps"Token de Azure DevOps del usuario API.
--azuredevops-user v0.9.0+
atlantis server --azuredevops-user="username@example.com"
# or
ATLANTIS_AZUREDEVOPS_USER="username@example.com"Nombre de usuario de Azure DevOps del usuario API.
--azuredevops-webhook-password v0.9.0+
atlantis server --azuredevops-webhook-password="password123"
# or (recommended)
ATLANTIS_AZUREDEVOPS_WEBHOOK_PASSWORD="password123"Contraseña de autenticación básica de Azure DevOps para webhooks entrantes (vea docs).
SECURITY WARNING
Si no se especifica, Atlantis no podrá validar que la llamada webhook entrante provino de su organización Azure DevOps. Esto significa que un atacante podría falsificar llamadas a Atlantis y hacer que realice acciones maliciosas. Debe especificarse mediante la variable de entorno ATLANTIS_AZUREDEVOPS_WEBHOOK_PASSWORD.
--azuredevops-webhook-user v0.9.0+
atlantis server --azuredevops-webhook-user="username@example.com"
# or
ATLANTIS_AZUREDEVOPS_WEBHOOK_USER="username@example.com"Nombre de usuario de autenticación básica de Azure DevOps para webhooks entrantes.
--bitbucket-api-user v0.36.0+
atlantis server --bitbucket-api-user="apiuser@example.com"
# or
ATLANTIS_BITBUCKET_API_USER="apiuser@example.com"Nombre de usuario de Bitbucket (normalmente un email) usado para autenticación API con Bitbucket Cloud. Esto se usa solo para llamadas API. Si no se especifica, Atlantis usará el valor de --bitbucket-user para autenticación API para mantener compatibilidad hacia atrás.
Nota:
- La compatibilidad hacia atrás es para soportar los APP Passwords existentes de Bitbucket que siguen siendo válidos hasta junio de 2026 (vea Atlassian's Bitbucket app password deprecation notice).
Clave del archivo de configuración:
bitbucket-api-user: apiuser@example.comVariable de entorno: ATLANTIS_BITBUCKET_API_USER
Nota: Este flag solo es relevante para integraciones de Bitbucket Cloud (bitbucket.org).
--bitbucket-base-url v0.36.0+
atlantis server --bitbucket-base-url="http://bitbucket.corp:7990/basepath"
# or
ATLANTIS_BITBUCKET_BASE_URL="http://bitbucket.corp:7990/basepath"URL base de la instalación de Bitbucket Server (también conocido como Stash). Debe incluir http:// o https://. Si usa Bitbucket Cloud (bitbucket.org), no la establezca. El valor predeterminado es https://api.bitbucket.org.
--bitbucket-token v0.36.0+
atlantis server --bitbucket-token="token"
# or (recommended)
ATLANTIS_BITBUCKET_TOKEN="token"App password de Bitbucket del usuario API.
--bitbucket-user v0.36.0+
atlantis server --bitbucket-user="myuser"
# or
ATLANTIS_BITBUCKET_USER="myuser"Nombre de usuario de Bitbucket usado para operaciones git. Para Bitbucket Cloud, si --bitbucket-api-user no se especifica, este valor también se usará para autenticación API.
--bitbucket-webhook-secret v0.36.0+
atlantis server --bitbucket-webhook-secret="secret"
# or (recommended)
ATLANTIS_BITBUCKET_WEBHOOK_SECRET="secret"Secreto usado para validar webhooks de Bitbucket.
SECURITY WARNING
Si no se especifica, Atlantis no podrá validar que la llamada webhook entrante provino de Bitbucket. Esto significa que un atacante podría falsificar llamadas a Atlantis y hacer que realice acciones maliciosas.
--blocked-extra-args
atlantis server --blocked-extra-args="-chdir,--chdir,-plugin-dir,--plugin-dir"
# or
ATLANTIS_BLOCKED_EXTRA_ARGS='-chdir,--chdir,-plugin-dir,--plugin-dir'Lista separada por comas de prefijos de flags de Terraform CLI que no están permitidos en args extra de comentarios (los flags después de --). El valor predeterminado es -chdir,--chdir,-plugin-dir,--plugin-dir.
Notas:
- Estos flags se bloquean para prevenir problemas de seguridad como recorrido de directorio de trabajo (
-chdir) o carga de providers maliciosos (-plugin-dir). - Establecer este flag reemplaza completamente la lista predeterminada. Para extender los valores predeterminados, inclúyalos junto con sus flags personalizados, p. ej.
-chdir,--chdir,-plugin-dir,--plugin-dir,-my-flag. - Acepta una lista separada por comas, p. ej.
-flag1,-flag2.
--checkout-depth v0.28.0+
atlantis server --checkout-depth=0
# or
ATLANTIS_CHECKOUT_DEPTH=0El número de commits a obtener de la rama. Se usa si --checkout-strategy=merge ya que la estrategia de checkout --checkout-strategy=branch (predeterminada) siempre usa por defecto un shallow clone con una profundidad de 1. El valor predeterminado es 0. Vea Checkout Strategy para más detalles.
--checkout-strategy v0.9.0+
atlantis server --checkout-strategy="<branch|merge>"
# or
ATLANTIS_CHECKOUT_STRATEGY="<branch|merge>"Cómo hacer checkout de pull requests. Use branch o merge. El valor predeterminado es branch. Vea Checkout Strategy para más detalles.
--config v0.1.3+
atlantis server --config="my/config/file.yaml"
# or
ATLANTIS_CONFIG="my/config/file.yaml"Archivo de configuración YAML donde también pueden establecerse flags. Vea Config File para más detalles.
--data-dir v0.1.3+
atlantis server --data-dir="path/to/data/dir"
# or
ATLANTIS_DATA_DIR="path/to/data/dir"Directorio donde Atlantis almacenará sus datos. Se creará si no existe. El valor predeterminado es ~/.atlantis. Atlantis almacenará aquí su base de datos, repos checked out, plans de Terraform por defecto y binarios de Terraform descargados. Si Atlantis pierde este directorio, los locks se perderán y los plans no aplicados se perderán.
Tenga en cuenta que el usuario atlantis está restringido a ~/.atlantis. Si establece el flag --data-dir en una ruta fuera del directorio home de Atlantis, asegúrese de otorgar al usuario atlantis los permisos correctos.
--default-tf-distribution v0.24.0+
atlantis server --default-tf-distribution="terraform"
# or
ATLANTIS_DEFAULT_TF_DISTRIBUTION="terraform"Qué distribución de TF usar. Puede establecerse en terraform o opentofu.
--default-tf-version v0.13.0
atlantis server --default-tf-version="v0.12.31"
# or
ATLANTIS_DEFAULT_TF_VERSION="v0.12.31"Versión de Terraform a usar por defecto. Se descargará en <data-dir>/bin/terraform<version> si no está en PATH. Vea Terraform Versions para más detalles.
--disable-apply-all v0.9.0+
atlantis server --disable-apply-all
# or
ATLANTIS_DISABLE_APPLY_ALL=trueDeshabilita el comando atlantis apply para que deba especificarse un proyecto/workspace/directorio específico para applies.
--disable-automerge-label v0.45.0+
atlantis server --disable-automerge-label="no-auto-merge"
# or
ATLANTIS_DISABLE_AUTOMERGE_LABEL="no-auto-merge"Deshabilitar atlantis automerge solo en pull requests con la etiqueta especificada. El valor predeterminado es una cadena vacía, por lo que ninguna etiqueta deshabilita automerge por defecto. Este flag no tiene efecto a menos que automerge esté habilitado con --automerge o automerge: true a nivel de repo.
--disable-autoplan v0.15.0+
atlantis server --disable-autoplan
# or
ATLANTIS_DISABLE_AUTOPLAN=trueDeshabilitar auto planning de atlantis.
--disable-autoplan-label v0.33.0+
atlantis server --disable-autoplan-label="no-autoplan"
# or
ATLANTIS_DISABLE_AUTOPLAN_LABEL="no-autoplan"Deshabilitar auto planning de atlantis solo en pull requests con la etiqueta especificada.
Si la propiedad disable-autoplan es true, este flag no tiene efecto.
--disable-global-apply-lock v0.17.0
atlantis server --disable-global-apply-lock
# or
ATLANTIS_DISABLE_GLOBAL_APPLY_LOCK=trueSi es true, elimina el botón en la UI que permite a los usuarios deshabilitar globalmente comandos apply.
--disable-markdown-folding v0.31.0+
atlantis server --disable-markdown-folding
# or
ATLANTIS_DISABLE_MARKDOWN_FOLDING=trueDeshabilitar folding en salida markdown usando la etiqueta html <details>.
--disable-repo-locking v0.16.1
atlantis server --disable-repo-locking
# or
ATLANTIS_DISABLE_REPO_LOCKING=trueImpide que atlantis bloquee proyectos y/o workspaces al ejecutar terraform.
--disable-unlock-label v0.33.0+
atlantis server --disable-unlock-label do-not-unlock
# or
ATLANTIS_DISABLE_UNLOCK_LABEL="do-not-unlock"Impide que atlantis desbloquee un pull request con esta etiqueta. El valor predeterminado es "" (feature deshabilitada).
--discard-approval-on-plan v0.29.0+
atlantis server --discard-approval-on-plan
# or
ATLANTIS_DISCARD_APPROVAL_ON_PLAN=trueSi se establece, descarta la aprobación si se ha ejecutado un nuevo plan. Actualmente solo soportado en GitHub y GitLab. Para GitLab se requiere un bot, group o project token para esta feature. Referencia: reset-approvals-of-a-merge-request
--emoji-reaction v0.29.0+
atlantis server --emoji-reaction eyes
# or
ATLANTIS_EMOJI_REACTION=eyesLa reacción emoji a usar para marcar comentarios procesados. Actualmente soportado en Gitea, GitHub y GitLab. Si no se especifica, Atlantis no usará una reacción emoji. El valor predeterminado es "" (cadena vacía).
--enable-diff-markdown-format v0.25.0+
atlantis server --enable-diff-markdown-format
# or
ATLANTIS_ENABLE_DIFF_MARKDOWN_FORMAT=trueHabilitar Atlantis para formatear la salida de Terraform plan en un formato amigable con markdown-diff para fines de colorización.
Útil para habilitar para usar con GitHub. Las líneas cambiadas dentro de diffs de heredoc y multiline-string de Terraform también se formatean para que renderizadores markdown conscientes de diff puedan colorearlas.
--enable-drift-detection
atlantis server --enable-drift-detection
# or
ATLANTIS_ENABLE_DRIFT_DETECTION=trueHabilitar endpoints API de detección de drift. La detección de drift no ejecuta Terraform apply, pero sí ejecuta el ciclo de vida normal de plan, incluyendo hooks pre-workflow configurados, workflows personalizados, pasos de plan personalizados y comandos Terraform plan. Cuando está habilitado, Atlantis inicializará almacenamiento en memoria para resultados de detección de drift y un servicio de remediación, haciendo funcionales los endpoints de detección de drift, estado y remediación solo-plan. Si webhooks de drift están configurados (event: drift), las ejecuciones de detección exitosas envían notificaciones a Slack o endpoints HTTP, incluyendo resultados heartbeat de no-drift. La detección de drift no omite team allowlists ni requisitos de estado PR plan_requirements como approved o mergeable; esas comprobaciones fallan de forma cerrada cuando no pueden evaluarse fuera de un pull request. Las acciones destructivas de apply de remediación de drift también requieren --enable-drift-remediation. El valor predeterminado es false.
--enable-drift-remediation
atlantis server --enable-drift-detection --enable-drift-remediation
# or
ATLANTIS_ENABLE_DRIFT_DETECTION=true
ATLANTIS_ENABLE_DRIFT_REMEDIATION=trueHabilitar acciones destructivas de apply de remediación de drift en el endpoint /api/drift/remediate. Este flag requiere --enable-drift-detection; sin él, las solicitudes action: "apply" son rechazadas mientras la detección de drift de solo lectura sigue disponible. Este flag no omite apply_requirements del repositorio; los requisitos que necesitan estado de pull request fallan de forma cerrada para solicitudes de remediación no PR. El valor predeterminado es false.
--enable-external-stores
atlantis server --enable-external-stores
# or
ATLANTIS_ENABLE_EXTERNAL_STORES=trueHabilitar backends de almacenamiento externo configurados en la repo config del lado del servidor (bloque external_stores). Cuando se establece, Atlantis lee la sección external_stores desde el YAML de configuración del repo para inicializar backends como S3 para persistencia de archivos plan.
--enable-policy-checks v0.17.0
atlantis server --enable-policy-checks
# or
ATLANTIS_ENABLE_POLICY_CHECKS=trueHabilita a atlantis para ejecutar policies del lado del servidor sobre el resultado de un terraform plan. Las policies están definidas en server side repo config.
--enable-profiling-api v0.25.0+
atlantis server --enable-profiling-api
# or
ATLANTIS_ENABLE_PROFILING_API=trueHabilitar endpoints net/http/pprof para continuous profiling de recursos usados por el servidor. Vea profiling Go programs para más información.
--enable-regexp-cmd v0.17.0
atlantis server --enable-regexp-cmd
# or
ATLANTIS_ENABLE_REGEXP_CMD=trueHabilitar Atlantis para usar expresiones regulares para ejecutar comandos plan/apply contra nombres de proyecto definidos cuando se pasa el flag -p con él.
Esto puede usarse para ejecutar todos los proyectos definidos (con la clave name) en atlantis.yaml usando atlantis plan -p .*.
El flag solo permitirá las regex listadas en la clave allowed_regexp_prefixes definida en el archivo repo atlantis.yaml. Si la clave no está definida, su valor predeterminado es [] que permitirá cualquier regex.
Esto aún no funcionará con -d y para usar -p los proyectos del repo deben estar definidos en el archivo repo atlantis.yaml.
Cuando --restrict-file-list está habilitado, los plans de proyecto por regex se limitan a coincidir con proyectos con archivos modificados en el pull request. Sin --restrict-file-list, los comandos de proyecto por regex todavía pueden ejecutarse contra todos los proyectos coincidentes.
SECURITY WARNING
No se supone que se use con --disable-apply-all. El comando atlantis apply -p .* omitirá la restricción y ejecutará apply en cada proyecto.
--executable-name v0.42.0+
atlantis server --executable-name="atlantis"
# or
ATLANTIS_EXECUTABLE_NAME="atlantis"Nombre ejecutable disparador del comando de comentario. El valor predeterminado es atlantis.
Esto es útil al ejecutar múltiples servidores Atlantis contra un solo repositorio.
Nota: la advertencia de error ortográfico "did you mean" solo se aplica al nombre ejecutable predeterminado (atlantis). Si establece un --executable-name personalizado, Atlantis no advertirá sobre comentarios que estén cerca de él según Levenshtein — esto evita advertencias espurias cuando múltiples servidores con nombres similares (p. ej. atlantis-dev y atlantis-prod) reciben el mismo comentario.
--fail-on-pre-workflow-hook-error v0.27.0+
atlantis server --fail-on-pre-workflow-hook-error
# or
ATLANTIS_FAIL_ON_PRE_WORKFLOW_HOOK_ERROR=trueFallar y no ejecutar el comando Atlantis solicitado si alguno de los hooks pre workflow produce error.
--gh-allow-mergeable-bypass-apply v0.30.0+
atlantis server --gh-allow-mergeable-bypass-apply
# or
ATLANTIS_GH_ALLOW_MERGEABLE_BYPASS_APPLY=trueFeature flag para habilitar la capacidad de usar el modo mergeable con required apply status check.
--gh-app-id v0.20.0+
atlantis server --gh-app-id="00000"
# or
ATLANTIS_GH_APP_ID="00000"ID de GitHub app. Si se establece, la autenticación de GitHub se realizará como an installation.
TIP
Una GitHub app puede crearse iniciando Atlantis primero, y luego apuntando su navegador a
$(hostname)/github-app/setupSerá redirigido a GitHub para crear una nueva app, y luego será redirigido a
$(hostname)/github-app/exchange-code?code=some-codeDespués de lo cual Atlantis mostrará las credenciales de su nueva app: el ID de su app, su --gh-webhook-secret generado y el contenido del archivo para --gh-app-key-file. Actualice su configuración de Atlantis en consecuencia y reinicie el servidor.
--gh-app-installation-id v0.20.0+
atlantis server --gh-app-installation-id="123"
# or
ATLANTIS_GH_APP_INSTALLATION_ID="123"El installation ID de una instancia específica de una aplicación GitHub. Normalmente este valor se deriva consultando a GitHub por la lista de instalaciones del ID suministrado mediante --gh-app-id y seleccionando la primera encontrada y donde múltiples instalaciones resultan en error. Use este flag si tiene múltiples instancias de Atlantis pero quiere usar una sola GitHub app ya instalada para todas ellas. Normalmente haría esto si está ejecutando un proxy como su única aplicación GitHub que hará proxy hacia una instancia Atlantis apropiada según la organización o usuario que activó el webhook.
--gh-app-key v0.20.0+
atlantis server --gh-app-key="-----BEGIN RSA PRIVATE KEY-----(...)"
# or
ATLANTIS_GH_APP_KEY="-----BEGIN RSA PRIVATE KEY-----(...)"La clave privada codificada en PEM para la GitHub App.
SECURITY WARNING
El contenido de la clave privada será visible para cualquiera que pueda ejecutar ps o mirar el historial del shell de la máquina donde Atlantis se está ejecutando. Use --gh-app-key-file para mitigar ese riesgo.
--gh-app-key-file v0.20.0+
atlantis server --gh-app-key-file="path/to/app-key.pem"
# or
ATLANTIS_GH_APP_KEY_FILE="path/to/app-key.pem"Ruta a un archivo de clave privada codificada en PEM de GitHub App. Si se establece, la autenticación de GitHub se realizará como an installation.
--gh-app-slug v0.16.1
atlantis server --gh-app-slug="myappslug"
# or
ATLANTIS_GH_APP_SLUG="myappslug"Una versión slugged del nombre de la GitHub app mostrada en comentarios de pull requests, etc. (no Atlantis App sino algo como atlantis-app). Atlantis usa el valor de este parámetro para identificar los comentarios que ha dejado en pull requests de GitHub. Esto se usa para funciones como --hide-prev-plan-comments. Necesita obtener este valor de su GitHub app; una forma es ir a la configuración de su App y abrir "Public page" desde la barra lateral izquierda. Su valor --gh-app-slug será la última parte de la URL, p. ej. https://github.com/apps/<slug>.
--gh-hostname v0.1.3+
atlantis server --gh-hostname="my.github.enterprise.com"
# or
ATLANTIS_GH_HOSTNAME="my.github.enterprise.com"Hostname de su instalación GitHub Enterprise. Si usa GitHub.com, no lo establezca. El valor predeterminado es github.com.
Para GitHub Enterprise Cloud, use el hostname del tenant, por ejemplo tenant.ghe.com. No incluya un esquema ni un prefijo api.; Atlantis deriva los endpoints API REST y GraphQL a partir del hostname.
--gh-org v0.1.3+
atlantis server --gh-org="myorgname"
# or
ATLANTIS_GH_ORG="myorgname"Nombre de organización GitHub. Establézcalo para habilitar la creación de una GitHub app privada para esta organización.
--gh-team-allowlist v0.41.0+
atlantis server --gh-team-allowlist="myteam:plan, secteam:apply, devops-team:apply, devops-team:import"
# or
ATLANTIS_GH_TEAM_ALLOWLIST="myteam:plan, secteam:apply, devops-team:apply, devops-team:import"En las versiones v0.35.0 y posteriores, el nombre de equipo GitHub solo puede ser un slug porque es inmutable.
En las versiones entre v0.21.0 y v0.34.0, el nombre de equipo GitHub puede ser un nombre o un slug.
En las versiones v0.20.1 y anteriores, el nombre de equipo GitHub requería el nombre de equipo sensible a mayúsculas y minúsculas.
Lista separada por comas de equipos GitHub y pares de permisos.
Por defecto, cualquier equipo puede plan y apply.
Se respeta la jerarquía de equipos de GitHub. Si un equipo en allowlist tiene equipos hijo, los miembros de esos equipos hijo heredan los comandos permitidos del equipo padre.
TIP
Si está usando policy checking, también debe incluir en allowlist el comando policy_check para que funcione en comandos manuales atlantis plan:
atlantis server --gh-team-allowlist="*:plan,*:policy_check,myteam:apply"Vea Policy Checking documentation para más detalles.
--gh-token v0.1.3+
atlantis server --gh-token="token"
# or (recommended)
ATLANTIS_GH_TOKEN="token"Token de GitHub del usuario API.
--gh-token-file v0.41.0+
atlantis server --gh-token-file="/path/to/token"
# or
ATLANTIS_GH_TOKEN_FILE="/path/to/token"Token de GitHub del usuario API. El token se carga regularmente desde disco para permitir la rotación del token sin necesidad de reiniciar el servidor Atlantis.
--gh-user v0.1.3+
atlantis server --gh-user="myuser"
# or
ATLANTIS_GH_USER="myuser"Nombre de usuario de GitHub del usuario API. Este usuario también es usado por el flag --hide-user-plan-comments y necesitará actualizarse si migra a github EMU.
--gh-webhook-secret v0.1.3+
atlantis server --gh-webhook-secret="secret"
# or (recommended)
ATLANTIS_GH_WEBHOOK_SECRET="secret"Secreto usado para validar webhooks de GitHub (vea GitHub: Validating webhook deliveries).
SECURITY WARNING
Si no se especifica, Atlantis no podrá validar que la llamada webhook entrante provino de GitHub. Esto significa que un atacante podría falsificar llamadas a Atlantis y hacer que realice acciones maliciosas.
--gitea-base-url v0.28.0+
atlantis server --gitea-base-url="http://your-gitea.corp:7990/basepath"
# or
ATLANTIS_GITEA_BASE_URL="http://your-gitea.corp:7990/basepath"URL base de la instalación Gitea. Debe incluir http:// o https://. El valor predeterminado es https://gitea.com si se deja vacío/ausente.
--gitea-page-size v0.28.0+
atlantis server --gitea-page-size=30
# or (recommended)
ATLANTIS_GITEA_PAGE_SIZE=30Número de elementos en una sola página en respuestas paginadas de Gitea.
Configuration dependent
El valor predeterminado cumple con la configuración estándar del servidor Gitea: DEFAULT_PAGING_NUM El valor válido más alto depende de la configuración del servidor Gitea: MAX_RESPONSE_ITEMS
--gitea-token v0.28.0+
atlantis server --gitea-token="token"
# or (recommended)
ATLANTIS_GITEA_TOKEN="token"App password de Gitea del usuario API.
--gitea-user v0.28.0+
atlantis server --gitea-user="myuser"
# or
ATLANTIS_GITEA_USER="myuser"Nombre de usuario de Gitea del usuario API.
--gitea-webhook-secret v0.28.0+
atlantis server --gitea-webhook-secret="secret"
# or (recommended)
ATLANTIS_GITEA_WEBHOOK_SECRET="secret"Secreto usado para validar webhooks de Gitea.
SECURITY WARNING
Si no se especifica, Atlantis no podrá validar que la llamada webhook entrante provino de Gitea. Esto significa que un atacante podría falsificar llamadas a Atlantis y hacer que realice acciones maliciosas.
--gitlab-group-allowlist v0.13.0+
atlantis server --gitlab-group-allowlist="myorg/mygroup:plan, myorg/secteam:apply, myorg/devops:apply, myorg/devops:import"
# or
ATLANTIS_GITLAB_GROUP_ALLOWLIST="myorg/mygroup:plan, myorg/secteam:apply, myorg/devops:apply, myorg/devops:import"Lista separada por comas de grupos GitLab y pares de permisos.
Por defecto, cualquier grupo puede plan y apply.
NOTE
Atlantis necesita poder ver los miembros de los grupos listados; los grupos inaccesibles o inexistentes se ignoran silenciosamente.
--gitlab-hostname v0.2.0+
atlantis server --gitlab-hostname="my.gitlab.enterprise.com"
# or
ATLANTIS_GITLAB_HOSTNAME="my.gitlab.enterprise.com"Hostname de su instalación GitLab Enterprise. Si usa GitLab.com, no lo establezca. El valor predeterminado es gitlab.com.
--gitlab-status-retry-enabled
atlantis server --gitlab-status-retry-enabled
# or
ATLANTIS_GITLAB_STATUS_RETRY_ENABLED=trueHabilitar lógica de reintento mejorada para actualizaciones de estado de pipeline de GitLab con exponential backoff.
El valor predeterminado es false.
--gitlab-token v0.2.0+
atlantis server --gitlab-token="token"
# or (recommended)
ATLANTIS_GITLAB_TOKEN="token"Token de GitLab del usuario API.
--gitlab-user v0.2.0+
atlantis server --gitlab-user="myuser"
# or
ATLANTIS_GITLAB_USER="myuser"Nombre de usuario de GitLab del usuario API.
--gitlab-webhook-secret v0.2.0+
atlantis server --gitlab-webhook-secret="secret"
# or (recommended)
ATLANTIS_GITLAB_WEBHOOK_SECRET="secret"Secreto usado para validar webhooks de GitLab.
SECURITY WARNING
Si no se especifica, Atlantis no podrá validar que la llamada webhook entrante provino de GitLab. Esto significa que un atacante podría falsificar llamadas a Atlantis y hacer que realice acciones maliciosas.
--help v0.1.3+
atlantis server --helpVer ayuda.
--hide-prev-plan-comments v0.19.0
atlantis server --hide-prev-plan-comments
# or
ATLANTIS_HIDE_PREV_PLAN_COMMENTS=trueOcultar comentarios de plan anteriores para reducir el desorden en los PRs. Esto solo está soportado actualmente en GitHub, GitLab y Bitbucket y no está habilitado por defecto.
Para Bitbucket, los comentarios se eliminan en lugar de ocultarse ya que Bitbucket no soporta ocultar comentarios.
Para GitHub, asegúrese de que --gh-user esté establecido apropiadamente o los comentarios no se ocultarán.
Al usar GitHub App, necesita establecer --gh-app-slug para habilitar esta feature.
--hide-unchanged-plan-comments v0.29.0+
atlantis server --hide-unchanged-plan-comments
# or
ATLANTIS_HIDE_UNCHANGED_PLAN_COMMENTS=trueEliminar comentarios de plan sin cambios del pull request.
Esto es útil cuando tiene muchos proyectos y quiere mantener el pull request limpio de comentarios inútiles.
--ignore-vcs-status-names v0.30.0+
atlantis server --ignore-vcs-status-names="status1,status2"
# or
ATLANTIS_IGNORE_VCS_STATUS_NAMES=status1,status2Lista separada por comas de nombres de estado VCS de otros servicios atlantis. Cuando gh-allow-mergeable-bypass-apply es true, ignorará status checks (p. ej. status1/plan, status1/apply, status2/plan, status2/apply) de otros servicios Atlantis al comprobar si el PR puede fusionarse. Actualmente solo implementado para GitHub.
--include-git-untracked-files v0.27.0+
atlantis server --include-git-untracked-files
# or
ATLANTIS_INCLUDE_GIT_UNTRACKED_FILES=trueIncluir archivos untracked de git en la lista de archivos modificados de Atlantis. Se usa por ejemplo con hooks pre-workflow de CDKTF que generan dinámicamente archivos Terraform.
--language v0.45.0+
atlantis server --language="en"
# or
ATLANTIS_LANGUAGE="en"Idioma usado para comentarios de pull request de Atlantis. El valor predeterminado es en.
Valores soportados:
en(inglés)es(español)
Atlantis normaliza valores de estilo locale (por ejemplo es-MX se resuelve como es). Si se configura un idioma no soportado y --language-config-file no está establecido, Atlantis devuelve un error de validación al iniciar.
Las cadenas de idioma integradas se cargan desde:
server/i18n/locales/en.yamlserver/i18n/locales/es.yaml
--language-config-file v0.45.0+
atlantis server --language="de" --language-config-file="/etc/atlantis/language.yaml"
# or
ATLANTIS_LANGUAGE_CONFIG_FILE="/etc/atlantis/language.yaml"Ruta opcional a un catálogo de idioma YAML personalizado. Los valores en este archivo sobrescriben el idioma integrado seleccionado, y se soportan sobrescrituras parciales.
Cuando --language-config-file está establecido, se permiten valores --language no soportados y Atlantis recurre al inglés integrado para las cadenas no especificadas.
Esquema YAML esperado:
pull_request_label: Pull Request (custom)
merge_request_label: Merge Request (custom)
command_titles:
plan: Plan (custom)
apply: Apply (custom)Para una personalización completa del texto markdown, siga usando --markdown-template-overrides-dir.
--locking-db-type v0.19.9+
atlantis server --locking-db-type="<boltdb|redis>"
# or
ATLANTIS_LOCKING_DB_TYPE="<boltdb|redis>"El tipo de base de datos de locking a usar para almacenar locks de plan y apply. El valor predeterminado es boltdb.
Notas:
- Si se establece en
boltdb, solo un proceso puede tener acceso a la instancia boltdb. - Si se establece en
redis, use--redis-hosty--redis-portpara modo de nodo único, o--redis-cluster-addressespara modo Redis Cluster. Use--redis-passwordy (opcionalmente)--redis-usernamesolo si su despliegue Redis requiere autenticación.
--log-level v0.1.3+
atlantis server --log-level="<debug|info|warn|error>"
# or
ATLANTIS_LOG_LEVEL="<debug|info|warn|error>"Nivel de log. El valor predeterminado es info.
--markdown-template-overrides-dir v0.21.0
atlantis server --markdown-template-overrides-dir="path/to/templates/"
# or
ATLANTIS_MARKDOWN_TEMPLATE_OVERRIDES_DIR="path/to/templates/"Esto estará disponible en v0.21.0.
Directorio donde Atlantis leerá sobrescrituras para plantillas markdown usadas para renderizar comentarios en pull requests. Las sobrescrituras de plantillas markdown pueden especificarse ya sea en archivos individuales, o todas juntas en un solo archivo. Todos los archivos de sobrescritura de plantilla deben tener la extensión .tmpl, de lo contrario no serán parseados.
Las plantillas markdown que pueden tener sobrescrituras pueden encontrarse en markdown templates directory
Tenga en cuenta que configuraciones como --enable-diff-markdown-format dependen de lógica definida en las plantillas. Es posible desviarse del comportamiento esperado, si no se tiene cuidado al sobrescribir las plantillas predeterminadas.
El valor predeterminado es el directorio home de atlantis /home/atlantis/.markdown_templates/ en /$HOME/.markdown_templates.
--max-comments-per-command v0.32.0+
atlantis server --max-comments-per-command=100
# or
ATLANTIS_MAX_COMMENTS_PER_COMMAND=100Limitar el número de comentarios publicados después de ejecutar un comando, para evitar spam en su VCS y que Atlantis sea throttled como resultado. El valor predeterminado es 100. Establezca esta opción en 0 para deshabilitar la truncación de logs. Tenga en cuenta que la truncación ocurrirá al inicio de la salida del comando, para preservar las partes más importantes de la salida, a menudo mostradas al final.
Cuando la salida del comando excede el límite de tamaño de comentario del VCS (o cuando este límite aplica), Atlantis divide la salida en múltiples comentarios usando división inteligente de comentarios. Los puntos de división se eligen para preservar la estructura markdown: el divisor detecta si está dentro de un bloque de código (``
``` ), a `<details>` block, or inline code ( ` ``), and inserts appropriate closing and continuation markers so that each comment renders correctly. Continuation comments are labeled with the command name (e.g. "Continued plan output from previous comment") when available.
--parallel-apply v0.22.0+
atlantis server --parallel-apply
# or
ATLANTIS_PARALLEL_APPLY=trueSi ejecutar operaciones apply en paralelo. El valor predeterminado es false. La declaración explícita en repo config tiene precedencia.
--parallel-plan v0.22.0+
atlantis server --parallel-plan
# or
ATLANTIS_PARALLEL_PLAN=trueSi ejecutar operaciones plan en paralelo. El valor predeterminado es false. La declaración explícita en repo config tiene precedencia.
--parallel-pool-size v0.16.0
atlantis server --parallel-pool-size=100
# or
ATLANTIS_PARALLEL_POOL_SIZE=100Tamaño máximo del wait group que ejecuta plans y applies en paralelo (si está habilitado). El valor predeterminado es 15
--pending-apply-status v0.36.0+
atlantis server --pending-apply-status
# or (recommended)
ATLANTIS_PENDING_APPLY_STATUS=trueEstablecer el estado del commit como pending cuando hay cambios planificados que aún no se han aplicado. Esto evita que merge requests se fusionen hasta que todos los Terraform applies estén completos si tiene Pipelines must succeed habilitado en su repositorio.
Cuando está habilitado, después de ejecutar atlantis plan, el estado del MR se mostrará como pending si hay cambios por aplicar. Una vez que todos los proyectos se hayan aplicado correctamente (o no muestren cambios), el estado se actualizará a success. Los proyectos sin cambios de Terraform se cuentan como actualizados en lugar de aplicados. Si un pull request tiene tanto proyectos actualizados como proyectos que todavía esperan apply, el estado de commit apply de Atlantis permanece pending hasta que todos los proyectos modificados se apliquen.
El valor predeterminado es false.
Solo soportado en GitLab
--port v0.1.3+
atlantis server --port=4141
# or
ATLANTIS_PORT=4141Puerto al que hacer bind. El valor predeterminado es 4141.
--quiet-policy-checks v0.32.0+
atlantis server --quiet-policy-checks
# or
ATLANTIS_QUIET_POLICY_CHECKS=trueExcluir comentarios de policy check de pull requests a menos que haya un error real de conftest. Esto también excluye advertencias. El valor predeterminado es false.
--redis-cluster-addresses
atlantis server --redis-cluster-addresses="redis-node-0:6379,redis-node-1:6379,redis-node-2:6379"
# or
ATLANTIS_REDIS_CLUSTER_ADDRESSES="redis-node-0:6379,redis-node-1:6379,redis-node-2:6379"Lista delimitada por comas de direcciones de nodos de clúster Redis en el formato host:port. Cuando se establece, Atlantis usa modo Redis Cluster en lugar de modo de nodo único. Esto es mutuamente excluyente con --redis-host/--redis-port (que se usan para modo de nodo único).
--redis-db v0.19.9+
atlantis server --redis-db=0
# or
ATLANTIS_REDIS_DB=0La base de datos Redis a usar cuando se usa un tipo Locking DB de redis. El valor predeterminado es 0.
--redis-host v0.19.9+
atlantis server --redis-host="localhost"
# or
ATLANTIS_REDIS_HOST="localhost"El hostname Redis cuando se usa un tipo Locking DB de redis.
--redis-insecure-skip-verify v0.19.9+
atlantis server --redis-insecure-skip-verify=false
# or
ATLANTIS_REDIS_INSECURE_SKIP_VERIFY=falseControla si el cliente Redis verifica la cadena de certificados y el nombre de host del servidor Redis. Si es true, acepta cualquier certificado presentado por el servidor y cualquier nombre de host en ese certificado. El valor predeterminado es false.
SECURITY WARNING
Si esto está habilitado, TLS es susceptible a ataques de machine-in-the-middle a menos que se use verificación personalizada.
--redis-password v0.19.9+
atlantis server --redis-password="password123"
# or (recommended)
ATLANTIS_REDIS_PASSWORD="password123"La contraseña Redis cuando se usa un tipo Locking DB de redis.
--redis-port v0.19.9+
atlantis server --redis-port=6379
# or
ATLANTIS_REDIS_PORT=6379El puerto Redis cuando se usa un tipo Locking DB de redis. El valor predeterminado es 6379.
--redis-tls-enabled v0.19.9+
atlantis server --redis-tls-enabled=false
# or
ATLANTIS_REDIS_TLS_ENABLED=falseHabilita una conexión TLS, con versión mínima 1.2, a Redis cuando se usa un tipo Locking DB de redis. El valor predeterminado es false.
--redis-username
atlantis server --redis-username="myuser"
# or
ATLANTIS_REDIS_USERNAME="myuser"El nombre de usuario Redis cuando se usa un tipo Locking DB de redis. Útil cuando Redis está configurado con autenticación basada en ACL.
--repo-allowlist v0.13.0
# NOTE: Use single quotes to avoid shell expansion of *.
atlantis server --repo-allowlist='github.com/myorg/*'
# or
ATLANTIS_REPO_ALLOWLIST='github.com/myorg/*'Atlantis requiere que especifique una allowlist de repositorios desde los que aceptará webhooks.
Notas:
- Acepta una lista separada por comas, p. ej.
definition1,definition2 - El formato es
{hostname}/{owner}/{repo}, p. ej.github.com/runatlantis/atlantis *coincide con cualquier carácter, p. ej.github.com/runatlantis/*coincidirá con todos los repos en la organización runatlantis- Una entrada que comience con
!la niega, p. ej.github.com/foo/*,!github.com/foo/barcoincidirá con todos los repos github en el ownerfooexceptobar. - Para Bitbucket Server:
{hostname}es el dominio sin esquema ni puerto,{owner}es el nombre del proyecto (no la key), e{repo}es el nombre del repo- Los repositorios de usuario (no proyecto) toman el formato:
{hostname}/{full name}/{repo}(p. ej.,bitbucket.example.com/Jane Doe/myatlantispara nombre de usuariojdoey nombre completoJane Doe, lo cual no es muy intuitivo)
- Los repositorios de usuario (no proyecto) toman el formato:
- Para Azure DevOps la allowlist toma una de dos formas:
{owner}.visualstudio.com/{owner}/{project}/{repo}odev.azure.com/{owner}/{project}/{repo} - Microsoft está en proceso de cambiar Azure DevOps a la segunda forma, por lo que puede ser más seguro especificar siempre ambos formatos en su allowlist de repo para cada repositorio hasta que el cambio esté completo.
Ejemplos:
- Incluir en allowlist
myorg/repo1ymyorg/repo2engithub.com--repo-allowlist=github.com/myorg/repo1,github.com/myorg/repo2
- Incluir en allowlist todos los repos bajo
myorgengithub.com--repo-allowlist='github.com/myorg/*'
- Incluir en allowlist todos los repos bajo
myorgengithub.com, excluyendomyorg/untrusted-repo--repo-allowlist='github.com/myorg/*,!github.com/myorg/untrusted-repo'
- Incluir en allowlist todos los repos en mi instalación GitHub Enterprise
--repo-allowlist='github.yourcompany.com/*'
- Incluir en allowlist todos los repos bajo el proyecto
myorgmyprojecten Azure DevOps--repo-allowlist='myorg.visualstudio.com/myorg/myproject/*,dev.azure.com/myorg/myproject/*'
- Incluir en allowlist todos los repositorios
--repo-allowlist='*'
--repo-config v0.5.0+
atlantis server --repo-config="path/to/repos.yaml"
# or
ATLANTIS_REPO_CONFIG="path/to/repos.yaml"Ruta a un archivo de configuración YAML de repos del lado del servidor. Vea Server Side Repo Config.
--repo-config-json v0.5.0+
atlantis server --repo-config-json='{"repos":[{"id":"/.*/", "apply_requirements":["mergeable"]}]}'
# or
ATLANTIS_REPO_CONFIG_JSON='{"repos":[{"id":"/.*/", "apply_requirements":["mergeable"]}]}'Especifique server-side repo config como una cadena JSON. Útil si no quiere escribir un archivo de configuración en disco. Vea Server Side Repo Config para más detalles.
TIP
Si especifica un Workflow, los step pueden especificarse de la siguiente manera:
{
"repos": [],
"workflows": {
"custom": {
"plan": {
"steps": [
"init",
{
"plan": {
"extra_args": ["extra", "args"]
}
},
{
"run": "my custom command"
}
]
}
}
}
}--restrict-file-list v0.28.0+
atlantis server --restrict-file-list
# or (recommended)
ATLANTIS_RESTRICT_FILE_LIST=true--restrict-file-list bloqueará solicitudes de plan de proyectos fuera de los archivos modificados en el pull request. Cuando --enable-regexp-cmd también está habilitado, los plans de proyecto por regex como atlantis plan -p .* se limitan a proyectos coincidentes con archivos modificados en el pull request. El valor predeterminado es false.
--share-plan-dir
atlantis server --share-plan-dir="path/to/local/plan/dir"
# or
ATLANTIS_SHARE_PLAN_DIR="path/to/local/plan/dir"Directorio donde Atlantis almacenará archivos Terraform plan locales. Si no se establece, esto toma por defecto el valor resuelto de --data-dir para que las instalaciones existentes mantengan el mismo layout en disco. Cuando se establece en un directorio diferente, los repositorios checked out permanecen bajo --data-dir y los archivos .tfplan generados usan el mismo layout de ruta de repo, pull request, workspace y proyecto bajo --share-plan-dir.
--silence-allowlist-errors v0.28.0+
atlantis server --silence-allowlist-errors
# or
ATLANTIS_SILENCE_ALLOWLIST_ERRORS=trueAlgunos usuarios usan el flag --repo-allowlist para controlar a qué repos Atlantis responde. Normalmente, si Atlantis recibe un webhook de pull request de un repo no listado en la allowlist, responderá con un comentario de error. Este flag deshabilita ese comentario.
Algunos usuarios encuentran esto útil porque prefieren agregar el webhook Atlantis a nivel de organización en lugar de en cada repo.
--silence-fork-pr-errors v0.28.0+
atlantis server --silence-fork-pr-errors
# or
ATLANTIS_SILENCE_FORK_PR_ERRORS=trueNormalmente, si Atlantis recibe un webhook de pull request desde un fork y --allow-fork-prs no está establecido, responderá con un comentario de error. Este flag deshabilita ese comentario.
--silence-no-projects v0.17.0
atlantis server --silence-no-projects
# or
ATLANTIS_SILENCE_NO_PROJECTS=true--silence-no-projects le dirá a Atlantis que ignore PRs si ninguno de los archivos modificados forma parte de un proyecto definido en el archivo atlantis.yaml. Este flag garantiza que un servidor Atlantis solo responda a sus proyectos declarados explícitamente. Esto no tiene efecto si los proyectos no están definidos en el atlantis.yaml a nivel de repo. Esto también silencia comandos dirigidos (p. ej. atlantis plan -d mydir o atlantis apply -p myproj) por lo que si el proyecto no está en el repo config atlantis.yaml, estos comandos no se ejecutarán ni informarán de vuelta en un comentario.
Esto es útil al ejecutar múltiples servidores Atlantis contra un solo repositorio para que pueda delegar trabajo a cada servidor Atlantis. También es útil cuando se usa con pre_workflow_hooks para generar dinámicamente un archivo atlantis.yaml.
--silence-vcs-status-no-plans v0.28.0+
atlantis server --silence-vcs-status-no-plans
# or
ATLANTIS_SILENCE_VCS_STATUS_NO_PLANS=true--silence-vcs-status-no-plans le dirá a Atlantis que ignore establecer estado VCS en plans si ninguno de los archivos modificados forma parte de un proyecto definido en el archivo atlantis.yaml.
--silence-vcs-status-no-projects v0.28.0+
atlantis server --silence-vcs-status-no-projects
# or
ATLANTIS_SILENCE_VCS_STATUS_NO_PROJECTS=true--silence-vcs-status-no-projects le dirá a Atlantis que ignore establecer estado VCS en cualquier comando si ninguno de los archivos modificados forma parte de un proyecto definido en el archivo atlantis.yaml.
--skip-clone-no-changes v0.15.0
atlantis server --skip-clone-no-changes
# or
ATLANTIS_SKIP_CLONE_NO_CHANGES=true--skip-clone-no-changes omitirá clonar el repo durante autoplan si no hay cambios en proyectos Terraform. Esto solo aplicará para GitHub y GitLab y solo para repos que tengan archivo atlantis.yaml. El valor predeterminado es false.
--slack-token v0.43.0+
atlantis server --slack-token=token
# or (recommended)
ATLANTIS_SLACK_TOKEN='token'Token API para notificaciones de Slack. Vea Using Slack hooks.
--ssl-cert-file v0.2.4+
atlantis server --ssl-cert-file="/etc/ssl/certs/my-cert.crt"
# or
ATLANTIS_SSL_CERT_FILE="/etc/ssl/certs/my-cert.crt"Archivo que contiene el certificado x509 usado para servir HTTPS. Si el cert está firmado por una CA, el archivo debe ser la concatenación del certificado del servidor, cualquier intermedio y el certificado de la CA.
--ssl-key-file v0.2.4+
atlantis server --ssl-key-file="/etc/ssl/private/my-cert.key"
# or
ATLANTIS_SSL_KEY_FILE="/etc/ssl/private/my-cert.key"Archivo que contiene la clave privada x509 que coincide con --ssl-cert-file.
--stats-namespace v0.43.0+
atlantis server --stats-namespace="myatlantis"
# or
ATLANTIS_STATS_NAMESPACE="myatlantis"Namespace para emitir stats/metrics. Vea la sección stats.
--tf-distribution v0.24.0+
DeprecatedObsoleto en favor de --default-tf-distribution.
--tf-download v0.18.0+
atlantis server --tf-download=false
# or
ATLANTIS_TF_DOWNLOAD=falseEl valor predeterminado es true. Permite a Atlantis listar y descargar versiones adicionales de Terraform. Establecer esto en false puede ser útil en un entorno air-gapped donde no hay un mirror de descarga disponible.
--tf-download-url v0.18.0+
atlantis server --tf-download-url="https://releases.company.com"
# or
ATLANTIS_TF_DOWNLOAD_URL="https://releases.company.com"Una URL alternativa para descargar versiones de Terraform si faltan. Útil en un entorno airgapped donde releases.hashicorp.com no está disponible. La estructura de directorios del endpoint personalizado debe coincidir con la de releases.hashicorp.com.
Esto no tiene impacto si --tf-download está establecido en false.
Esta configuración aún no está soportada cuando --tf-distribution está establecido en opentofu.
--tfe-hostname v0.8.3+
atlantis server --tfe-hostname="my-terraform-enterprise.company.com"
# or
ATLANTIS_TFE_HOSTNAME="my-terraform-enterprise.company.com"Hostname de su instalación Terraform Enterprise para usarse junto con --tfe-token. Vea Terraform Cloud para más detalles. Si usa Terraform Cloud (es decir, no tiene su propia instalación Terraform Enterprise) no es necesario establecerlo ya que el valor predeterminado es app.terraform.io.
--tfe-local-execution-mode v0.8.3+
atlantis server --tfe-local-execution-mode
# or
ATLANTIS_TFE_LOCAL_EXECUTION_MODE=trueHabilite esto si está usando modo de ejecución local (en lugar del modo de ejecución remota de TFE/C). Vea Terraform Cloud para más detalles.
--tfe-token v0.8.3+
atlantis server --tfe-token="xxx.atlasv1.yyy"
# or (recommended)
ATLANTIS_TFE_TOKEN='xxx.atlasv1.yyy'Un token para integración Terraform Cloud/Terraform Enterprise. Vea Terraform Cloud para más detalles.
--use-tf-plugin-cache v0.26.0+
atlantis server --use-tf-plugin-cache=falseEstablézcalo en false si desea deshabilitar la caché de plugins de terraform.
Este flag es útil cuando se tienen múltiples proyectos que necesitan ejecutar un plan y apply en el mismo PR para evitar la condición de carrera de plugin_cache_dir concurrentemente; este es un issue conocido de terraform, más información:
El efecto de la condición de carrera es más evidente al usar configuración paralela para ejecutar plan y apply. Deshabilitar el uso de la caché de plugins impactará el rendimiento al iniciar un nuevo plan o apply, pero en grandes despliegues Atlantis con múltiples proyectos y módulos compartidos el uso de --parallel_plan y --parallel_apply es obligatorio para una gestión eficiente de los PRs.
--var-file-allowlist v0.19.5
atlantis server --var-file-allowlist='/path/to/tfvars/dir'
# or
ATLANTIS_VAR_FILE_ALLOWLIST='/path/to/tfvars/dir'Lista separada por comas de rutas de directorios adicionales desde donde pueden leerse variable definition files. Las rutas en este argumento deben ser rutas absolutas. Las rutas relativas y el globbing actualmente no están soportados. Si este argumento no se proporciona, su valor predeterminado es el directorio de datos de Atlantis, determinado por el argumento --data-dir.
--vcs-status-name v0.42.0+
atlantis server --vcs-status-name="atlantis-dev"
# or
ATLANTIS_VCS_STATUS_NAME="atlantis-dev"Nombre usado para identificar Atlantis al actualizar el estado de un pull request. El valor predeterminado es atlantis.
Esto es útil al ejecutar múltiples servidores Atlantis contra un solo repositorio para que pueda dar a cada servidor Atlantis su propio nombre único para evitar que los estados colisionen.
--web-basic-auth v0.1.0+
atlantis server --web-basic-auth
# or
ATLANTIS_WEB_BASIC_AUTH=trueHabilitar Basic Authentication en el servicio web Atlantis.
--web-password v0.1.0+
atlantis server --web-password="atlantis"
# or
ATLANTIS_WEB_PASSWORD="atlantis"Contraseña usada para Basic Authentication en el servicio web Atlantis. El valor predeterminado es atlantis.
--web-username v0.1.0+
atlantis server --web-username="atlantis"
# or
ATLANTIS_WEB_USERNAME="atlantis"Nombre de usuario usado para Basic Authentication en el servicio web Atlantis. El valor predeterminado es atlantis.
--webhook-http-headers v0.35.0+
atlantis server --webhook-http-headers='{"Authorization":"Bearer some-token","X-Custom-Header":["value1","value2"]}'
# or
ATLANTIS_WEBHOOK_HTTP_HEADERS='{"Authorization":"Bearer some-token","X-Custom-Header":["value1","value2"]}'Headers adicionales añadidos a cada payload HTTP POST al usar http webhooks proporcionados como una cadena JSON. La clave del mapa es el nombre del header y el valor es el valor del header (cadena) o valores (array de cadenas).
--websocket-check-origin v0.19.0+
atlantis server --websocket-check-origin
# or
ATLANTIS_WEBSOCKET_CHECK_ORIGIN=truePermitir conexión de websockets solo cuando se origine desde el servidor web Atlantis en ejecución
--write-git-creds v0.11.0+
atlantis server --write-git-creds
# or
ATLANTIS_WRITE_GIT_CREDS=trueEscribir un archivo .git-credentials con el usuario y token del proveedor para permitir clonar módulos privados sobre HTTPS o SSH. Vea Git Credential Store documentation para más información.
Siga el git::ssh