fix(init): make scaffolded agents runnable in-cluster (env secret provider + file scheduler)#177
Merged
Merged
Conversation
forge init only wrote a secrets.providers block when HasSecrets was true (i.e. inline secret env vars were passed with values). Platform scaffolds (agent-builder) deliberately pass NO credentials to 'forge init' — secrets are injected later as Kubernetes env vars. With no secrets block, the runtime builds no secret provider, so it never reads env-injected keys like OPENAI_API_KEY; ResolveModelConfig finds no key and falls back to the StubExecutor, failing every task with 'agent execution not configured for framework forge'. The env provider is harmless when no matching env vars exist, so always include it. encrypted-file is still gated on HasSecrets (inline secrets).
naveen-kurra
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Agents scaffolded by the platform (
forge init --non-interactive) deploy but can't actually run. Two distinct startup failures, both rooted in the init template:1. No secret provider → StubExecutor
forge.yamlhad nosecrets:block (only emitted whenHasSecrets, i.e. inline secrets passed with values — the platform injects secrets later as k8s env). With noenvprovider, the runtime never reads the OS-injectedOPENAI_API_KEY;ResolveModelConfigfinds no key → StubExecutor → every task fails withagent execution not configured for framework "forge".2. auto scheduler → KubernetesBackend → crashloop
Once #1 is fixed and a real LLM executor initializes, the scheduler starts.
SchedulerConfig.Backenddefaults toauto→ Kubernetes backend in-cluster, which requiresscheduler.kubernetes.service_url. The platform deploys via its own manifests (notforge package), so service_url is unset → startup errorkubernetes scheduler backend: scheduler.kubernetes.service_url is required→ CrashLoopBackOff.Fix (init template)
envsecret provider (harmless when empty);encrypted-filestays gated onHasSecrets.scheduler.backend: file(in-process ticker, no service_url). Opt into the K8s CronJob backend withbackend: kubernetes+kubernetes.service_url.Verified
forge init x --non-interactive -f forge -m openainow scaffolds bothsecrets.providers: [env]andscheduler.backend: file. On a live deploy: secret loads from env ("msg":"secret loaded","provider":"env") and the agent no longer crashloops on the scheduler.🤖 Generated with Claude Code