Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 3 additions & 2 deletions docs/ADRs/0028-gitlab-support.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
---
title: "28. GitLab Support Architecture"
status: Deprecated
status: Superseded
superseded_by: "0043-gitlab-per-repo-support"
relates_to:
- agent-infrastructure
- agent-architecture
Expand All @@ -17,7 +18,7 @@ Date: 2026-04-29

## Status

Deprecated
Superseded by [ADR 0043](0043-gitlab-per-repo-support.md)

## Context

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -141,7 +141,7 @@ caller's perspective.
inline, which partially mitigates this.
- **GitHub-specific mechanism:** `workflow_call` and `secrets:` passthrough are
GitHub Actions primitives with no direct equivalent in other CI systems.
Multi-forge support ([ADR 0028](0028-gitlab-support.md)) will need its own
Multi-forge support ([ADR 0043](0043-gitlab-per-repo-support.md), supersedes [ADR 0028](0028-gitlab-support.md)) will need its own
distribution mechanism (e.g., GitLab CI/CD Components or `include:`)
independent of this ADR.
- **Scaffold output changes:** `fullsend admin install` will emit thin callers
Expand Down
6 changes: 3 additions & 3 deletions docs/ADRs/0036-agent-execution-sandbox.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ Accepted

## Context

Fullsend agents execute within isolated sandboxes that enforce security boundaries: filesystem access control, network policy enforcement, and credential isolation (ADR-0017, ADR-0025). The current implementation uses OpenShell with per-agent L7 network policies and runs on GitHub Actions runners. With GitLab support proposed (ADR-0028), the execution architecture needs to work on both GitHub Actions and GitLab CI runners.
Fullsend agents execute within isolated sandboxes that enforce security boundaries: filesystem access control, network policy enforcement, and credential isolation (ADR-0017, ADR-0025). The current implementation uses OpenShell with per-agent L7 network policies and runs on GitHub Actions runners. With GitLab support proposed (ADR-0043, supersedes ADR-0028), the execution architecture needs to work on both GitHub Actions and GitLab CI runners.

The sandbox architecture has multiple concerns that need to be resolved together:

Expand All @@ -31,7 +31,7 @@ The sandbox architecture has multiple concerns that need to be resolved together
4. **Resource limits**: CPU, memory, and timeout constraints need platform-independent expression
5. **OpenShell integration**: The sandbox runtime (OpenShell gateway + L7 policies + providers) must work in all executor environments

The GitLab support design (ADR-0028) explicitly deferred this decision: "The agent execution environment is orthogonal to the CI/CD dispatch architecture. GitLab runner configuration, sandbox isolation, and compute architecture should be documented separately."
The GitLab support design (ADR-0043, supersedes ADR-0028) explicitly deferred this decision: "The agent execution environment is orthogonal to the CI/CD dispatch architecture. GitLab runner configuration, sandbox isolation, and compute architecture should be documented separately."

The forge abstraction (ADR-0005) keeps dispatch logic platform-neutral. This ADR addresses what happens *after* the dispatch pipeline triggers an agent job: how the agent actually executes.

Expand Down Expand Up @@ -288,7 +288,7 @@ The implementation document is structured for iterative evolution as the sandbox
- ADR-0005: Forge abstraction layer (dispatch is platform-neutral, execution must also be)
- ADR-0017: Credential isolation for sandboxed agents (zero credentials in sandbox)
- ADR-0025: Provider credential delivery (OpenShell providers for credential injection)
- [ADR-0028: GitLab Support Architecture](0028-gitlab-support.md) (dispatch pipelines, explicitly deferred agent execution environment)
- [ADR-0043: GitLab per-repo support](0043-gitlab-per-repo-support.md) (supersedes [ADR-0028](0028-gitlab-support.md); dispatch pipelines, explicitly deferred agent execution environment)
- ADR-0030: OpenShell sandbox interaction model (defines the agent-harness communication protocol)
- [agent-infrastructure.md](../problems/agent-infrastructure.md): Infrastructure layer exploration, SIG Agent Sandbox evaluation
- [OpenShell](https://github.com/NVIDIA/OpenShell): Sandbox runtime with L7 network policy enforcement
597 changes: 597 additions & 0 deletions docs/ADRs/0043-gitlab-per-repo-support.md

Large diffs are not rendered by default.

3 changes: 2 additions & 1 deletion docs/architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -127,7 +127,7 @@ One concrete implementation option is [`oidcx`](https://github.com/oxidecomputer
- ~~What identity model fits best — separate bot accounts per agent role, a single bot account with role metadata, GitHub App installations, or something else?~~ Decided in [ADR 0007](ADRs/0007-per-role-github-apps.md).
- How are credentials rotated and revoked, and who has authority to do that?
- Does the identity provider integrate with existing secrets management, or is it a new system?
- How will per-role identity work on GitLab and Forgejo, which lack GitHub's app manifest flow?
- How will per-role identity work on GitLab and Forgejo, which lack GitHub's app manifest flow? (For GitLab: [ADR 0043](ADRs/0043-gitlab-per-repo-support.md) decided on a single bot project access token retrieved via OIDC/WIF — no per-role isolation initially, but WIF attribute conditions enable future per-role scoping. Forgejo remains open.)

## Agent Dispatch and Coordination Layer

Expand All @@ -138,6 +138,7 @@ The existing design principle is that [the repo is the coordinator](problems/age
**Decided:**

- Event-driven stage dispatch runs synchronously via `workflow_call` to preserve run correlation in the GitHub Actions UI (see [ADR 0041](ADRs/0041-synchronous-workflow-call-event-dispatch.md)).
- For GitLab: dispatch uses a webhook bridge Cloud Function that translates GitLab webhook events into Pipeline Trigger API calls with `ref=main` hardcoded. The pipeline's dispatch job routes events to stage-specific jobs via dotenv variables (see [ADR 0043](ADRs/0043-gitlab-per-repo-support.md)).

**Open questions:**

Expand Down
2 changes: 1 addition & 1 deletion docs/plans/agent-execution-environment.md
Original file line number Diff line number Diff line change
Expand Up @@ -922,7 +922,7 @@ spec:
- [ADR-0036: Agent Execution Sandbox Architecture](../ADRs/0036-agent-execution-sandbox.md)
- [ADR-0017: Credential Isolation for Sandboxed Agents](../ADRs/0017-credential-isolation-for-sandboxed-agents.md)
- [ADR-0025: Provider Credential Delivery](../ADRs/0025-provider-credential-delivery-for-sandboxed-agents.md)
- [ADR-0028: GitLab Support Architecture](../ADRs/0028-gitlab-support.md)
- [ADR-0043: GitLab per-repo support](../ADRs/0043-gitlab-per-repo-support.md) (supersedes [ADR-0028](../ADRs/0028-gitlab-support.md))
- [agent-infrastructure.md](../problems/agent-infrastructure.md): Infrastructure layer exploration
- [OpenShell Documentation](https://docs.nvidia.com/openshell/)
- [Sigstore Cosign](https://docs.sigstore.dev/cosign/overview/)
Expand Down
Loading
Loading