docs(evidence): record ci troubleshooting and resolution notes
Some checks failed
CI Pipeline / Backend Build & Test (push) Failing after 1m7s
CI Pipeline / Frontend Lint, Test & Build (push) Successful in 54s
CI Pipeline / Infrastructure Validation (push) Successful in 3s

This commit is contained in:
WorkClub Automation
2026-03-06 22:44:33 +01:00
parent 3313bd0fba
commit 0b6bdd42fd
2 changed files with 375 additions and 3 deletions

View File

@@ -1,7 +1,7 @@
Task: Validate Gitea Actions run on push/PR (remote evidence)
Timestamp: 2026-03-06T21:00:15Z
Result: BLOCKED (cannot validate successful run yet)
Result: PARTIAL SUCCESS (authenticated verification available; runner execution still blocked)
Evidence collected:
@@ -18,6 +18,28 @@ Evidence collected:
- Command: git ls-tree -r --name-only origin/main | grep '^.gitea/workflows/'
- Output: (empty)
Update after push + token-based API verification:
4) Workflow is now present and active on remote:
- API: GET /api/v1/repos/MasterMito/work-club-manager/actions/workflows
- Workflow: `.gitea/workflows/ci.yml` (`state: active`)
5) Push event created workflow run:
- API: GET /api/v1/repos/MasterMito/work-club-manager/actions/runs
- Run: id `102`, run_number `1`, event `push`, branch `main`, workflow `ci.yml`
6) Parallel jobs were created for the run:
- API: GET /api/v1/repos/MasterMito/work-club-manager/actions/runs/102/jobs
- Jobs observed (all `queued`):
- Backend Build & Test
- Frontend Lint, Test & Build
- Infrastructure Validation
7) Runner execution state:
- Repeated polling of run `102` for ~30s remained `status: queued`
- Indicates workflow dispatch works, but no runner consumed jobs during observation window
Conclusion:
- Local workflow exists in working tree but is not yet present on remote branch.
- Successful push/PR CI run validation cannot be completed until workflow is committed/pushed and API/web access to runs is available.
- Remote CI pipeline is installed correctly and triggers on push.
- Required parallel jobs are instantiated as expected.
- Full pass/fail evidence is currently blocked by runner availability (queued state does not complete).

View File

@@ -3433,3 +3433,353 @@ Modified TestAuthHandler to emit `preferred_username` claim:
**Key Learning**: Gitea/GitHub Actions `paths-ignore` at trigger level is more robust than runtime conditionals checking event payload fields that may not exist.
---
## Frontend Lint/Test/Build Stabilization - CI Ready (2026-03-06)
### Problem Statement
The `frontend-ci` job in Gitea Actions was failing with:
- 62 `@typescript-eslint/no-explicit-any` errors across e2e tests, auth code, and test files
- 1 `react-hooks/set-state-in-effect` error in tenant-context and useActiveClub hook
- Numerous unused variable warnings in protected layout and task detail page
### Key Learnings
#### 1. **Replacing `any` with Proper TypeScript Types**
**Pattern 1: Playwright Page Type**
```typescript
// ❌ Bad (any type)
async function selectClubIfPresent(page: any) { ... }
// ✅ Good (proper import type)
async function selectClubIfPresent(page: import('@playwright/test').Page) { ... }
```
**Pattern 2: Next-Auth Account Type**
```typescript
// ❌ Bad
token.clubs = (account as any).clubs || {}
// ✅ Good
token.clubs = (account as Record<string, unknown>).clubs as Record<string, string> || {}
```
**Pattern 3: Vitest Mock Returns**
```typescript
// ❌ Bad
(useSession as any).mockReturnValue({ data: null, status: 'loading' } as any);
// ✅ Good
(useSession as ReturnType<typeof vi.fn>).mockReturnValue({ data: null, status: 'loading' });
```
**Pattern 4: Global Fetch Mock**
```typescript
// ❌ Bad
(global.fetch as any).mockResolvedValue({ ok: true, json: async () => ({}) });
// ✅ Good
(global.fetch as ReturnType<typeof vi.fn>).mockResolvedValue({ ok: true, json: async () => ({}) });
```
**Pattern 5: Test Setup Mocks**
```typescript
// ❌ Bad
global.localStorage = localStorageMock as any;
// ✅ Good
const localStorageMock = {
getItem: vi.fn(),
setItem: vi.fn(),
removeItem: vi.fn(),
clear: vi.fn(),
length: 0,
key: vi.fn(),
};
global.localStorage = localStorageMock as unknown as Storage;
```
**Why `as unknown as Storage`?** TypeScript requires two-step assertion when types don't overlap. Mock has vi.fn() types but Storage expects actual functions.
#### 2. **react-hooks/set-state-in-effect Error - The React Hooks Strict Rule**
**The Problem:**
ESLint rule `react-hooks/set-state-in-effect` forbids ANY setState call directly in useEffect body. React docs state effects should:
1. Synchronize with external systems (DOM, cookies, network)
2. Subscribe to external updates (calling setState in callbacks only)
**❌ Anti-Pattern (Triggers Error):**
```typescript
useEffect(() => {
if (status === 'authenticated' && clubs.length > 0) {
const stored = localStorage.getItem('activeClubId');
if (stored && clubs.find(c => c.id === stored)) {
setActiveClubId(stored); // ❌ setState in effect body
}
}
}, [status, clubs]);
```
**✅ Solution 1: Lazy Initialization + useMemo**
```typescript
// Initialize from localStorage on mount
const [activeClubId, setActiveClubId] = useState<string | null>(() => {
if (typeof window === 'undefined') return null;
return localStorage.getItem('activeClubId');
});
// Derive computed value without setState
const computedActiveClubId = useMemo(() => {
if (status !== 'authenticated' || !clubs.length) return activeClubId;
return determineActiveClub(clubs, activeClubId);
}, [status, clubs, activeClubId]);
```
**✅ Solution 2: Helper Function Outside Component**
```typescript
function determineActiveClub(clubs: Club[], currentActiveId: string | null): string | null {
if (!clubs.length) return null;
const stored = typeof window !== 'undefined' ? localStorage.getItem('activeClubId') : null;
if (stored && clubs.find(c => c.id === stored)) return stored;
if (currentActiveId && clubs.find(c => c.id === currentActiveId)) return currentActiveId;
return clubs[0].id;
}
```
**Why This Works:**
- Lazy initializer runs ONCE on mount (no effect needed)
- `useMemo` recomputes derived state based on dependencies (pure function)
- No setState in effect body = no cascading renders
**Why Not useRef?**
Even with `useRef` to track initialization, calling setState in effect triggers the lint error. The rule is absolute: no synchronous setState in effect body.
#### 3. **Removing Unused Imports and Variables**
**Pattern 1: Unused Component Imports**
```typescript
// ❌ Triggers warning
import { Button } from '@/components/ui/button';
import { LogOut } from 'lucide-react'; // Not used in JSX
// ✅ Remove unused
import { SignOutButton } from '@/components/sign-out-button'; // Already wraps Button + LogOut
```
**Pattern 2: Unused Hook Destructuring**
```typescript
// ❌ Triggers warning
const { data: session, status } = useSession(); // session never used
// ✅ Remove unused
const { status } = useSession();
```
**Pattern 3: Unused Function Parameters**
```typescript
// ❌ In test mock
DropdownMenuTrigger: ({ children, asChild }: { children: React.ReactNode, asChild?: boolean })
=> <div>{children}</div> // asChild never used
// ✅ Remove unused param
DropdownMenuTrigger: ({ children }: { children: React.ReactNode })
=> <div>{children}</div>
```
#### 4. **TypeScript Build Errors vs ESLint Warnings**
**Critical Distinction:**
- **bun run lint** → ESLint checks (code quality, patterns, style)
- **bun run build** → TypeScript compiler checks (type safety, structural correctness)
**Example: Storage Mock Type Error**
```typescript
// ✅ Passes lint
global.localStorage = localStorageMock as Storage;
// ❌ Fails tsc (Next.js build)
// Error: Type '{ getItem: Mock }' missing 'length' and 'key' from Storage
// ✅ Passes both lint and build
const localStorageMock = {
getItem: vi.fn(),
setItem: vi.fn(),
removeItem: vi.fn(),
clear: vi.fn(),
length: 0,
key: vi.fn(),
};
global.localStorage = localStorageMock as unknown as Storage;
```
**Why `as unknown as Storage`?**
- Direct `as Storage` assertion fails because Mock<Procedure> ≠ function types
- Two-step assertion: `as unknown` erases type, then `as Storage` applies target type
- TypeScript allows this for test mocks where exact type match is impossible
### Files Modified
**E2E Tests (Playwright types):**
- `frontend/e2e/auth.spec.ts` — 2 functions: page type from `any` → `import('@playwright/test').Page`
- `frontend/e2e/shifts.spec.ts` — 2 functions: page type from `any` → `import('@playwright/test').Page`
**Auth Code:**
- `frontend/src/auth/auth.ts` — JWT callback: `account as any` → `account as Record<string, unknown>`
**Test Files (Vitest mocks):**
- `frontend/src/components/__tests__/auth-guard.test.tsx` — 6 tests: removed 29 `as any` casts, replaced with `ReturnType<typeof vi.fn>`
- `frontend/src/components/__tests__/club-switcher.test.tsx` — 3 tests: removed 6 `as any` casts
- `frontend/src/components/__tests__/shift-detail.test.tsx` — 3 tests: removed 5 `as any` casts
- `frontend/src/components/__tests__/task-detail.test.tsx` — 3 tests: removed 9 `as any` casts
- `frontend/src/components/__tests__/task-list.test.tsx` — 1 test setup: removed 2 `as any` casts
- `frontend/src/hooks/__tests__/useActiveClub.test.ts` — 7 tests: removed 3 `as any` casts, removed unused imports
- `frontend/src/lib/__tests__/api.test.ts` — 9 tests: removed 3 `as any` casts
**Test Setup:**
- `frontend/src/test/setup.ts` — Added `length: 0` and `key: vi.fn()` to localStorage mock, used `as unknown as Storage`
**React Hooks (set-state-in-effect fixes):**
- `frontend/src/contexts/tenant-context.tsx` — Replaced useEffect setState with lazy init + useMemo pattern
- `frontend/src/hooks/useActiveClub.ts` — Replaced useEffect setState with lazy init + useMemo pattern
**Unused Variables:**
- `frontend/src/app/(protected)/layout.tsx` — Removed unused `Button` and `LogOut` imports
- `frontend/src/app/(protected)/tasks/[id]/page.tsx` — Removed unused `useRouter` import
- `frontend/src/components/auth-guard.tsx` — Removed unused `session` variable from destructuring
### Build Verification Results
**✅ bun run lint** — 0 errors, 0 warnings
- All 62 `@typescript-eslint/no-explicit-any` errors resolved
- All 2 `react-hooks/set-state-in-effect` errors resolved
- All unused variable warnings cleaned up
**✅ bun run test** — 45/45 tests passing
- 11 test files, 1.44s duration
- All existing functionality preserved (no behavior changes)
**✅ bun run build** — Next.js production build successful
- TypeScript compilation clean
- 12 routes generated (4 static, 5 dynamic, 3 API)
- Static generation completed in 157.3ms
### Pattern Summary: When to Use Each Type Assertion
**1. Direct Type Assertion (Preferred)**
```typescript
const value = mockObject as SomeType;
```
Use when: Types overlap sufficiently (TypeScript can verify relationship)
**2. Two-Step Assertion (Test Mocks)**
```typescript
const value = mockObject as unknown as SomeType;
```
Use when: Types don't overlap (e.g., vi.fn() Mock → function type)
**3. Generic Type Helper**
```typescript
(mockedFunction as ReturnType<typeof vi.fn>).mockReturnValue(...);
```
Use when: Vitest mock functions need method access (.mockReturnValue, .mockResolvedValue)
**4. Import Type (No Runtime Import)**
```typescript
function myFunc(arg: import('package').Type) { ... }
```
Use when: Only need type (not value), avoid bundling entire package for type
### Gotchas Avoided
- ❌ **DO NOT** use useRef to bypass `react-hooks/set-state-in-effect` — rule still triggers on setState in effect body
- ❌ **DO NOT** add dependencies to satisfy effect without solving root cause — leads to infinite re-render loops
- ❌ **DO NOT** cast localStorage mock as `Storage` directly — tsc requires all interface properties (length, key)
- ❌ **DO NOT** use `any` in Playwright test helpers — import proper `Page` type from '@playwright/test'
- ❌ **DO NOT** ignore unused variable warnings — they often indicate dead code or missed refactoring
- ✅ **DO** use lazy state initializer for localStorage reads (runs once on mount)
- ✅ **DO** use useMemo for derived state (pure computation, no setState)
- ✅ **DO** use `ReturnType<typeof vi.fn>` for Vitest mocks needing .mockReturnValue
- ✅ **DO** add ALL Storage interface properties to localStorage mock (even if unused)
### Impact on CI Pipeline
**Before:** `frontend-ci` job failed in `bun run lint` step with 62 errors
**After:** `frontend-ci` job passes all 3 steps:
1. ✅ `bun run lint` — 0 errors
2. ✅ `bun run test` — 45/45 passing
3. ✅ `bun run build` — production build successful
**Next Steps:**
- Monitor CI runs to ensure stability across different Node/Bun versions
- Consider adding lint step to pre-commit hook (local verification)
- Document these patterns in project README for future contributors
---
## Task: Infra CI Kustomize Setup Fix (2026-03-06)
### Problem
- Gitea CI infra job failed at `imranismail/setup-kustomize@v2` step
- Error: `Could not satisfy version range 5.4.1: HttpError: 404 page not found`
- Third-party GitHub action unable to resolve kustomize v5.4.1 from releases
### Root Cause
- Action relies on GitHub releases API pattern that may not match Kubernetes SIG release structure
- kustomize releases tagged as `kustomize/v5.4.1` (not `v5.4.1` directly)
- Action maintainer may not handle this prefix or release lookup broke
### Solution Applied
Replaced action with direct download from official Kubernetes SIG releases:
```yaml
- name: Install Kustomize
run: |
curl -Lo kustomize.tar.gz https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize%2Fv5.4.1/kustomize_v5.4.1_linux_amd64.tar.gz
tar -xzf kustomize.tar.gz
chmod +x kustomize
sudo mv kustomize /usr/local/bin/
kustomize version
```
### Why This Works
1. **Direct download**: Bypasses action's version resolution logic
2. **URL encoding**: `%2F` represents `/` in URL for `kustomize/v5.4.1` tag
3. **Deterministic**: Official release artifact, no third-party dependencies
4. **Verifiable**: `kustomize version` confirms installation before validation steps
### Verification
Local validations passed:
- `docker compose config --quiet` → ✅ (with ignorable version key deprecation warning)
- `kustomize build infra/k8s/base` → ✅
- `kustomize build infra/k8s/overlays/dev` → ✅ (with commonLabels deprecation warning)
### Files Modified
- `.gitea/workflows/ci.yml`: Replaced action with manual install script (lines 131-136)
### Strategy Choice
**Alternative options rejected**:
- **Different action**: Other actions may have same issue or introduce new dependencies
- **Version change**: 5.4.1 is current stable, no reason to downgrade/upgrade
- **Preinstalled binary**: Gitea runner may not have kustomize, explicit install safer
**Chosen: Direct download** because:
- Zero third-party GitHub action dependencies
- Transparent installation (visible in CI logs)
- Easy to update version (change URL only)
- Standard pattern for installing CLI tools in CI
### Lessons
1. **Third-party actions are fragile**: Prefer official actions or direct installation
2. **Version resolution matters**: kustomize uses `kustomize/vX.Y.Z` tag prefix
3. **Local validation insufficient**: Action failure was remote-only (local had kustomize installed)
4. **CI robustness**: Manual install adds ~5s overhead but removes external dependency risk
### Production Impact
- Infra job now reliably validates compose + kustomize manifests
- No risk of action maintainer abandonment or API breakage
- Future version updates require only URL change (no action configuration)