Skip to content

Declare provider credentials in profiles and drop _NOOP_* placeholders for OpenShell 0.1 #1512

Closed

Description

@waynesun09

Problem

fullsend is moving to OpenShell v0.1.1 (fullsend-ai/fullsend#7233). OpenShell 0.1 is a clean break from 0.0.x. provider create now validates every credential against the provider profile's declared credentials:, and none of this repo's profiles declares any. On a v0.1.1 gateway every fleet run stops before the sandbox is created:

provider create "vertex-ai" failed: ... message: "provider credentials are not declared by profile 'fullsend-vertex-ai': _NOOP_VERTEX_AI"
provider create "github-ro" failed: ... message: "provider credentials are not declared by profile 'fullsend-github-ro': GH_TOKEN"

The _NOOP_* placeholder credentials worked around OpenShell refusing an empty credential map (NVIDIA/OpenShell#1978, now closed). 0.1.x creates a provider with no credentials.

Change

  1. Declare real credentials in their profiles. Each profile whose provider passes a token declares it. The form follows the upstream reference profile (examples/governance-interceptor/profiles/github.yaml at v0.1.1) and fullsend's own fullsend-openai profile:

    credentials:
      - name: api_token
        description: GitHub token
        env_vars: [GH_TOKEN]
        required: true
    • fullsend-github-ro, fullsend-github-code: GH_TOKEN
    • fullsend-gitlab-ro, fullsend-gitlab-rw, fullsend-gitlab-code: GITLAB_TOKEN
    • fullsend-jira-ro: JIRA_TOKEN

    Credential delivery is still placeholder substitution by the sandbox proxy. 0.1.x adds that a placeholder only resolves at the endpoints its profile declares.

  2. Remove the _NOOP_* credentials from providers/vertex-ai.yaml, gitleaks.yaml, package-registries.yaml and github-artifacts.yaml, along with their credentials: block. Nothing else in those files changes.

  3. .github/workflows/functional-tests.yml writes a schema v1 gateway config, which 0.1.x rejects. Write schema v2, matching fullsend's action.yml in #7233:

    [openshell]
    version = 2
    
    [openshell.gateway]
    compute_driver = "podman"
    
    [openshell.drivers.podman]
    supervisor_image = "ghcr.io/nvidia/openshell/supervisor:${OPENSHELL_VERSION}"
    health_check_interval_secs = 10

    This part changes a workflow file, so it has to come from a maintainer rather than the code agent.

Verified

With the profile declarations in (1) and fullsend built from #7233, local fullsend run triage --forge github on OpenShell v0.1.1 (podman, macOS arm64) passed on Claude and on codex: providers ready, gh authenticated through the proxy, Validation: passed. All ten profiles pass openshell provider profile lint on v0.1.1.

Merge order

This change and fullsend#7233 land together. This repo's CI reads the OpenShell version from fullsend main, so it goes green once #7233 merges. Before that, validate by running the functional-tests workflow with fullsend_ref pointing at #7233's branch. No 0.0.x compatibility is kept.

Activity

  1. fullsend-ai-triage commented on Sep 26, 2026

    @fullsend-ai-triage

    🤖 Finished Triage · ✅ Success · Started 1:28 PM UTC · Completed 1:35 PM UTC

    Commit: fa6f19d · View workflow run →

    Runtime: claude · Model: sonnet → claude-sonnet-5 · Effort: high · Cost: $0.68

  2. fullsend-ai-triage commented on Sep 26, 2026

    @fullsend-ai-triage

    Thanks for the detailed writeup and the local verification steps. Before this can be dispatched for implementation, one thing needs to be untangled: the change is scoped to land together with fullsend's move to OpenShell v0.1.1, referenced here as fullsend-ai/fullsend#7233, with CI expected to "go green once #7233 merges."

    Checking that reference: fullsend-ai/fullsend#7233 is currently an open, docs-only pull request that annotates ADR 0030 with the sandbox exec/stop signal contract (closing issue #7229) -- it does not touch action.yml, openshell-version.sh, or any gateway configuration. fullsend's main branch still pins OPENSHELL_VERSION=0.0.116 and writes gateway schema version = 1 in both action.yml and .github/scripts/openshell-version.sh. A search across open, closed, and merged issues/PRs in fullsend-ai/fullsend did not surface any other tracking item for the actual v0.1.1 version bump or the schema-v2 gateway config change.

    OpenShell v0.1.1 itself is a real upstream release, and the proposed credentials: block format matches both the upstream reference profile and fullsend's own fullsend-openai scaffold template, so the mechanics described here look sound. But without a real, in-flight migration to point at, merging the credential-declaration changes now -- especially removing the _NOOP_* placeholders -- risks breaking this repo's CI while it is still running on OpenShell 0.0.x, since the issue itself notes no 0.0.x compatibility is kept.

    A tracking issue for the actual OpenShell v0.1.1 migration has been proposed in fullsend-ai/fullsend so this work can be sequenced correctly. Separately, note that item 3 (the functional-tests.yml schema-v2 change) is a workflow-file edit, which the issue itself already flags as needing to come from a maintainer rather than the code agent -- that constraint still applies once the prerequisite above is resolved.

    Could you confirm whether #7233 was the intended reference, or point to the correct PR/issue tracking the version bump? That will let this be re-triaged against the right dependency.

    Could not create automatically (file manually or update create_issues.allow_targets in config.yaml):

    Prerequisite: fullsend-ai/fullsend — Migrate to OpenShell v0.1.1: bump pinned version and gateway config to schema v2

    #1512 needs to declare real provider credentials in its OpenShell profiles and drop _NOOP_* placeholder credentials, but that change is only safe once this repo's gateway actually runs OpenShell v0.1.1 -- v0.1.x is the release that stops refusing an empty credential map (NVIDIA/OpenShell#1978) and instead validates every passed credential against the profile's declared credentials: block.

    Currently:

    • .github/scripts/openshell-version.sh pins OPENSHELL_VERSION=0.0.116.
    • action.yml and .github/scripts/openshell-version.sh both write a gateway config with [openshell]\nversion = 1.
    • Downstream repos such as fullsend-ai/agents read this version via .github/scripts/openshell-version.sh in their own CI (see fullsend-ai/agents .github/workflows/functional-tests.yml), so they cannot adopt v0.1.1-only provider behavior until this repo bumps the pin.

    Requested work:

    1. Bump OPENSHELL_VERSION/OPENSHELL_SHA in .github/scripts/openshell-version.sh to v0.1.1.
    2. Update the gateway config written in action.yml (and any other in-repo templates) to schema v2, e.g.:
      [openshell]
      version = 2
      
      [openshell.gateway]
      compute_driver = "podman"
      
      [openshell.drivers.podman]
      supervisor_image = "ghcr.io/nvidia/openshell/supervisor:${OPENSHELL_VERSION}"
      health_check_interval_secs = 10
    3. Confirm existing scaffold profiles that already declare credentials: (e.g. internal/scaffold/fullsend-repo/profiles/fullsend-openai.yaml) still validate cleanly under v0.1.1's stricter provider-create checks.

    Once this lands, downstream repos whose CI reads the pinned version from this repo (e.g. fullsend-ai/agents) can safely declare real credentials in their own OpenShell profiles and remove _NOOP_* placeholder workarounds.

  3. waynesun09 commented on Sep 26, 2026

    @waynesun09
    MemberAuthor

    /fs-code Do not sign off. No git commit -s, no Signed-off-by trailer; the post-code guard rejects it and the branch is never pushed.

    The dependency now exists: fullsend-ai/fullsend#7233 pins OpenShell v0.1.1 (openshell-version.sh 0.1.1 / 4ce767fc0), writes the schema v2 gateway config and drops fullsend's own _NOOP_* scaffold credentials. The two land together, and no 0.0.x compatibility is kept.

    Change exactly these files and nothing else:

    1. Profiles: add a credentials: block right after the category: line. Use this shape (the same as fullsend's internal/scaffold/fullsend-repo/profiles/fullsend-openai.yaml, minus its OpenAI-only fields):
      credentials:
        - name: api_token
          description: GitHub token
          env_vars: [GH_TOKEN]
          required: true
      • profiles/fullsend-github-ro.yaml, profiles/fullsend-github-code.yaml: GH_TOKEN, description GitHub token
      • profiles/fullsend-gitlab-ro.yaml, profiles/fullsend-gitlab-rw.yaml, profiles/fullsend-gitlab-code.yaml: GITLAB_TOKEN, description GitLab token
      • profiles/fullsend-jira-ro.yaml: JIRA_TOKEN, description Jira API token
        Do not add auth_style, header_name or refresh. Leave endpoints, binaries and comments unchanged.
    2. Providers: delete the credentials: block holding the _NOOP_* key (and any comment line that exists only to explain it) in providers/vertex-ai.yaml, providers/gitleaks.yaml, providers/package-registries.yaml and providers/github-artifacts.yaml. Leave the name: and type: lines.
    3. Everything that documents or tests those files. grep -rn "_NOOP_" . must return nothing outside git history. Update any doc or test that shows a _NOOP_* credential, or a profile with no credentials: block for a token-bearing provider.
    4. Do NOT edit .github/workflows/. The schema v2 change to functional-tests.yml needs workflow permissions; a maintainer adds it to this PR.

    Run make lint before finishing.

  4. fullsend-ai-coder commented on Sep 26, 2026

    @fullsend-ai-coder
    Contributor

    🤖 Finished Code · ✅ Success · Started 1:38 PM UTC · Completed 1:48 PM UTC

    Commit: fa6f19d · View workflow run →

    Runtime: pi · Model: xai/grok-4.6 · Effort: high · Cost: $4.54

  5. added 2 commits that reference this issue on Sep 26, 2026
  6. added 2 commits that reference this issue on Sep 29, 2026
  7. added 3 commits that reference this issue on Sep 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions