feat(seed): default to podman for seed generation

[devin-ai-integration[bot]]

Description

Link to Devin run: https://app.devin.ai/sessions/b57689ec676f443b8671e6de05e5af10 Requested by: Niels Swimberghe ([email protected]) / @Swimburger

This PR adds support for separate docker and podman configurations in seed.yml files, allowing generators to specify different build commands and image configurations for each container runtime. It also refactors Docker-specific terminology to container-agnostic naming throughout the codebase.

Changes Made

• Added optional podman fields to Fern API definition (config.yml):
  • TestConfiguration.podman: optional<TestContainerConfiguration>
  • PublishDocker.podman: optional<PublishContainerConfiguration>
• Renamed configuration types for container-agnostic terminology:
  • TestDockerConfiguration → TestContainerConfiguration (with deprecated alias)
  • PublishDockerConfiguration → PublishContainerConfiguration (with deprecated alias)
• Updated DockerTestRunner to determine container runtime based on config presence:
  • Uses podman if test.podman config exists
  • Falls back to docker if only test.docker config exists
  • Explicit runner parameter still takes precedence
• Updated publishGenerator to support podman publishing with same fallback logic
• Added podmanTagLatest scripts to all generator package.json files
• Refactored container terminology throughout codebase (e.g., DockerExecutionEnvironment → ContainerExecutionEnvironment)
• Regenerated TypeScript config types from Fern definition with deprecated aliases for backward compatibility

Critical Fix

The implementation addresses a runtime mismatch issue where:

1. Images were being built with docker (via dockerTagLatest commands)
2. But run with podman (due to hardcoded default)
3. Podman couldn't find images in docker's image store, causing 163 CI test failures with unauthorized errors when trying to pull from registry

The solution determines the effective runner based on config presence, ensuring the same runtime is used for both building and running containers.

Testing

• [x] Lint checks pass (pnpm run check)
• [x] TypeScript config types regenerated successfully
• [x] All CI checks pass (251 passes, 0 failures)
• [x] Backward compatibility maintained through deprecated type aliases

Review Checklist

Critical areas to review:

1. Runner selection logic in DockerTestRunner constructor (lines 15-22) - verify it correctly determines docker vs podman based on config presence
2. Backward compatibility - confirm generators without podman config still work with docker
3. Publish code in publishGenerator.ts (line 70) - verify it uses the same selection logic
4. Container runtime consistency - ensure the same runtime is used for building, tagging, and running containers
5. Type safety - verify the deprecated aliases (TestDockerConfiguration, PublishDockerConfiguration) work correctly and maintain backward compatibility

Known limitations:

• Most generators don't have podman config yet, so they'll continue using docker (as intended)
• CI environment must have docker available for generators without podman config

[devin-ai-integration[bot]]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• [ ] Disable automatic comment and CI monitoring

[Swimburger]

Refactor the code so it doesn't directly refer to Docker, instead to container, and the code receives whether it should be run in docker or podman. If this is a breaking change, add backwards-compatible deprecated aliases.