James Wampler
1556b486d2
## Summary - Fix a chain of QA CI issues: Docker build/health-check flakiness, NuGet vuln pins, then adds the post-deploy integration + Playwright smoke suite and works through everything needed to make it actually run on the self-hosted `qa` runner (musl/Alpine job container, no node/dotnet/curl preinstalled, docker-outside-of-docker networking). - Adds a fixed dev/QA seed admin user + fixed Development environment API key so integration tests and e2e specs have a stable target. - Pins Aspire's `AppHost.cs` ports/credentials to match the docker-compose local dev defaults. - Adds `tests/api/MicCheck.Api.Tests.Integration` coverage for disabled flags, environment-document bootstrap, identity override precedence, auth login, and unauthorized access; adds a Playwright e2e suite under `src/admin/e2e` (login, nav, context selection, features CRUD/toggle). - Adds a `smoke-qa` CI job that runs both suites against the just-deployed QA stack, working around: no curl/node/dotnet on the bare runner, musl vs glibc (Playwright browsers run via the official `mcr.microsoft.com/playwright` image instead), and the runner's job-container network isolation (reach the QA stack via the docker bridge gateway IP; `docker cp` instead of a bind mount to get files into the playwright container, since paths don't cross the docker-outside-of-docker boundary). ## Test plan - [x] Unit tests pass (dotnet test tests/api/MicCheck.Api.Tests.Unit, 243 passed) - [x] API integration suite passes against the real QA stack in CI - [x] Playwright e2e suite passes against the real QA stack in CI (verified 3/3 locally against a real dev API + vite server for the flakiest spec) - [x] Full CI pipeline (build → deploy-qa → smoke-qa) green end to end on the qa runner Reviewed-on: #3
31 lines
1.3 KiB
TypeScript
31 lines
1.3 KiB
TypeScript
import { test, expect } from '@playwright/test';
|
|
import { authFile } from './global-setup';
|
|
|
|
test.use({ storageState: authFile });
|
|
|
|
/**
|
|
* The seeded DB (DatabaseSeeder) provides exactly one org, one project ("My Project"), and
|
|
* three environments (Development/Staging/Production), so the selectors auto-populate without
|
|
* needing to create anything first. Most feature screens require both a project and an
|
|
* environment to be selected before they render real content.
|
|
*/
|
|
test('project and environment context is selectable and persists across a reload', async ({ page }) => {
|
|
await page.goto('/features');
|
|
|
|
const projectSelect = page.getByTestId('project-select').locator('input');
|
|
const envSelect = page.getByTestId('env-select').locator('input');
|
|
|
|
await expect(projectSelect).not.toHaveValue('');
|
|
await expect(envSelect).not.toHaveValue('');
|
|
|
|
// Explicitly re-select the project via the dropdown to prove the selector itself works,
|
|
// not just the auto-select-on-load behavior.
|
|
await page.getByTestId('project-select').click();
|
|
await page.getByRole('option', { name: 'My Project' }).click();
|
|
await expect(projectSelect).toHaveValue('My Project');
|
|
|
|
await page.reload();
|
|
await expect(page.getByTestId('project-select').locator('input')).not.toHaveValue('');
|
|
await expect(page.getByTestId('env-select').locator('input')).not.toHaveValue('');
|
|
});
|