Add a throwaway domain controller job to CI for the domain modules

Abierto
  • ¿Algo no está bien?
#124 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
github-actions, powershell
Área
ci-cd, documentation, testing

Línea de trabajo

Start in .github/workflows/ci.yml by adding a windows-dc job that promotes a runner with Install-ADDSForest and runs Pester domain-controller tests. Read docs/Conventions.md section 9 and docs/lab/README.md for runner expectations, and mirror the existing linux/windows job triggers. Done means the new job fails on promotion failure, a sample Domain Admins test passes, and firewall tests on other runners finish without losing connection.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

area: tests-ci platform: windows type: build

Location & Context

.github/workflows/ci.yml (the linux and windows jobs), docs/Conventions.md section 9, docs/lab/README.md, Roadmap section 4.1 ("Where do real-host tests run?"). Both test jobs already set LAB_REALSYSTEM=1, so each module's real-host tests under tests/ run on the disposable Ubuntu and Windows Server runners as soon as they are written. The third runner that Conventions section 9 plans, a throwaway single domain controller, does not exist yet.

Current Behavior

The domain modules cannot be tested on a real domain in CI: #84 (domain read-only checks), #82 (admin accounts, which on a domain controller are domain accounts), #83 (Windows protocol settings on a domain controller) and #103 (the remaining domain hardening). Their acceptance tests would only run in the lab, by hand, so a change can break them unnoticed until the next lab pass.

Real-host module tests on the existing runners also have a risk the core tests did not: a default-deny firewall (#78) or a rotated credential (#75) can cut the runner off from GitHub, so the job hangs instead of failing.

Remediation Plan

  1. Add a windows-dc job that promotes a fresh Windows Server runner to a single-domain forest (Install-ADDSForest with a throwaway domain name and password made at run time), then runs the Pester tests tagged for a domain controller with LAB_REALSYSTEM=1.
  2. Run it only when files under the domain modules, core/, platform/windows/ or the workflow change, as the other jobs do.
  3. Give the real-host module tests a rule for the runners: keep the runner's own outbound connection to GitHub allowed, set a job timeout, and undo every change at the end of the test even when it fails.
  4. Record in docs/lab/README.md which module tests run on which runner, and keep the older-system tests in the lab.
  5. Tests:
    • The new job fails if the promotion fails, rather than skipping the domain tests.
    • A sample domain test (a planted extra member of Domain Admins is listed) passes on the runner.
    • A firewall test on the Ubuntu and Windows runners finishes and reports, without losing the runner.
Lenguaje dominante
PowerShell
Estrellas
0
Forks
0
Merge medio
54 min
PR fusionados (30 d)
43

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnetdork/Labyrinth

Todos los issues de dotnetdork/Labyrinth

Issues similares

Más issues de DevOps

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.