Skip to content

ci probe (will delete) #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wi-kshitij-nagvekar wants to merge 6 commits into from
Closed

ci probe (will delete) #3

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
bfb6106
feat(api): add sync to skill sources
nogoodusername Sep 22, 2026
667b470
feat(controller): wire skill sync reload into agent servers
nogoodusername Sep 22, 2026
2ac552d
feat(git-sync): reload the OpenCode server after a sync
nogoodusername Sep 22, 2026
32e09b0
test: cover skill sync and server reload
nogoodusername Sep 22, 2026
303a057
docs: explain skill sync and server reload
nogoodusername Sep 22, 2026
a9920e3
ci: probe push trigger
wi-kshitij-nagvekar Sep 22, 2026
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
20 changes: 20 additions & 0 deletions api/v1alpha1/context_types.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -139,6 +139,26 @@ type GitSync struct {
// +optional
// +kubebuilder:default=HotReload
Policy GitSyncPolicy `json:"policy,omitempty"`

// Reload asks the OpenCode server to re-scan its configuration after a
// HotReload update lands, so the change takes effect without a Pod restart.
//
// This matters for content the server snapshots at instance start — most
// notably skills, which are discovered once and cached in memory. Updating
// files on disk alone is invisible to a running server.
//
// The reload is performed by the git-sync sidecar calling the server's
// reload endpoint. To avoid interrupting work in progress, the reload is
// deferred while any session is busy and retried on the next sync cycle.
//
// Only effective with Policy: HotReload, and only for long-running Agents
// (ignored for ephemeral Task pods).
//
// This field is an opt-in for Git contexts. Skill sources always reload
// when sync is enabled, since re-scanning is the point of syncing skills;
// set sync on a skill only if you want that behavior.
// +optional
Reload bool `json:"reload,omitempty"`
}

// GitSecretReference references a Secret for Git authentication.
Expand Down
21 changes: 21 additions & 0 deletions api/v1alpha1/skill_types.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,8 @@ type SkillSource struct {
// GitSkillSource defines a Git repository as a skill source.
// The repository should contain SKILL.md files organized as one-folder-per-skill,
// following the standard skill format (Markdown with YAML frontmatter).
//
// +kubebuilder:validation:XValidation:rule="!has(self.sync) || !has(self.sync.policy) || self.sync.policy != 'Rollout'",message="sync.policy Rollout is not supported for skills; use HotReload"
type GitSkillSource struct {
// Repository is the Git repository URL.
// Supported protocols: https://, http://, git@ (SSH).
Expand Down Expand Up @@ -97,4 +99,23 @@ type GitSkillSource struct {
// Reuses the same Secret format as context Git.
// +optional
SecretRef *GitSecretReference `json:"secretRef,omitempty"`

// Sync configures periodic synchronization of the skill repository for
// long-running Agents (ignored for ephemeral Task pods, which run once).
//
// When enabled, a git-sync sidecar polls the remote and updates the cloned
// content in place. Because OpenCode discovers skills only at instance
// start, updated files alone are not enough for a running server: after a
// change is detected the sidecar asks the server to re-scan, so changed
// skills become visible without a Pod restart.
//
// Only the HotReload policy is supported for skills. Rollout would require
// comparing remote refs in the controller and is rejected here.
//
// Note: skills selected via "names" are mounted from fixed subpaths, so
// edits to those skills are picked up but newly added skill directories are
// not mounted until the Pod restarts. Omit "names" to mount the whole
// directory and pick up additions without a restart.
// +optional
Sync *GitSync `json:"sync,omitempty"`
}
5 changes: 5 additions & 0 deletions api/v1alpha1/zz_generated.deepcopy.go
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

86 changes: 86 additions & 0 deletions charts/kubeopencode/crds/kubeopencode.io_agents.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -357,6 +357,26 @@ spec:
- HotReload
- Rollout
type: string
reload:
description: |-
Reload asks the OpenCode server to re-scan its configuration after a
HotReload update lands, so the change takes effect without a Pod restart.

This matters for content the server snapshots at instance start — most
notably skills, which are discovered once and cached in memory. Updating
files on disk alone is invisible to a running server.

The reload is performed by the git-sync sidecar calling the server's
reload endpoint. To avoid interrupting work in progress, the reload is
deferred while any session is busy and retried on the next sync cycle.

Only effective with Policy: HotReload, and only for long-running Agents
(ignored for ephemeral Task pods).

This field is an opt-in for Git contexts. Skill sources always reload
when sync is enabled, since re-scanning is the point of syncing skills;
set sync on a skill only if you want that behavior.
type: boolean
type: object
required:
- repository
Expand Down Expand Up @@ -6301,9 +6321,75 @@ spec:
required:
- name
type: object
sync:
description: |-
Sync configures periodic synchronization of the skill repository for
long-running Agents (ignored for ephemeral Task pods, which run once).

When enabled, a git-sync sidecar polls the remote and updates the cloned
content in place. Because OpenCode discovers skills only at instance
start, updated files alone are not enough for a running server: after a
change is detected the sidecar asks the server to re-scan, so changed
skills become visible without a Pod restart.

Only the HotReload policy is supported for skills. Rollout would require
comparing remote refs in the controller and is rejected here.

Note: skills selected via "names" are mounted from fixed subpaths, so
edits to those skills are picked up but newly added skill directories are
not mounted until the Pod restarts. Omit "names" to mount the whole
directory and pick up additions without a restart.
properties:
enabled:
description: |-
Enabled enables periodic sync of the Git repository.
When true, a sidecar container (HotReload) or controller polling (Rollout)
is used to keep the Git content up-to-date.
type: boolean
interval:
description: |-
Interval is the polling interval for checking remote changes.
Default: "5m".
type: string
policy:
default: HotReload
description: |-
Policy determines how changes are applied.
HotReload (default): sidecar pulls changes in-place, no Pod restart.
Rollout: controller detects changes and triggers Deployment rolling update.
enum:
- HotReload
- Rollout
type: string
reload:
description: |-
Reload asks the OpenCode server to re-scan its configuration after a
HotReload update lands, so the change takes effect without a Pod restart.

This matters for content the server snapshots at instance start — most
notably skills, which are discovered once and cached in memory. Updating
files on disk alone is invisible to a running server.

The reload is performed by the git-sync sidecar calling the server's
reload endpoint. To avoid interrupting work in progress, the reload is
deferred while any session is busy and retried on the next sync cycle.

Only effective with Policy: HotReload, and only for long-running Agents
(ignored for ephemeral Task pods).

This field is an opt-in for Git contexts. Skill sources always reload
when sync is enabled, since re-scanning is the point of syncing skills;
set sync on a skill only if you want that behavior.
type: boolean
type: object
required:
- repository
type: object
x-kubernetes-validations:
- message: sync.policy Rollout is not supported for skills;
use HotReload
rule: '!has(self.sync) || !has(self.sync.policy) || self.sync.policy
!= ''Rollout'''
name:
description: |-
Name is a unique identifier for this skill source.
Expand Down
86 changes: 86 additions & 0 deletions charts/kubeopencode/crds/kubeopencode.io_agenttemplates.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -291,6 +291,26 @@ spec:
- HotReload
- Rollout
type: string
reload:
description: |-
Reload asks the OpenCode server to re-scan its configuration after a
HotReload update lands, so the change takes effect without a Pod restart.

This matters for content the server snapshots at instance start — most
notably skills, which are discovered once and cached in memory. Updating
files on disk alone is invisible to a running server.

The reload is performed by the git-sync sidecar calling the server's
reload endpoint. To avoid interrupting work in progress, the reload is
deferred while any session is busy and retried on the next sync cycle.

Only effective with Policy: HotReload, and only for long-running Agents
(ignored for ephemeral Task pods).

This field is an opt-in for Git contexts. Skill sources always reload
when sync is enabled, since re-scanning is the point of syncing skills;
set sync on a skill only if you want that behavior.
type: boolean
type: object
required:
- repository
Expand Down Expand Up @@ -6043,9 +6063,75 @@ spec:
required:
- name
type: object
sync:
description: |-
Sync configures periodic synchronization of the skill repository for
long-running Agents (ignored for ephemeral Task pods, which run once).

When enabled, a git-sync sidecar polls the remote and updates the cloned
content in place. Because OpenCode discovers skills only at instance
start, updated files alone are not enough for a running server: after a
change is detected the sidecar asks the server to re-scan, so changed
skills become visible without a Pod restart.

Only the HotReload policy is supported for skills. Rollout would require
comparing remote refs in the controller and is rejected here.

Note: skills selected via "names" are mounted from fixed subpaths, so
edits to those skills are picked up but newly added skill directories are
not mounted until the Pod restarts. Omit "names" to mount the whole
directory and pick up additions without a restart.
properties:
enabled:
description: |-
Enabled enables periodic sync of the Git repository.
When true, a sidecar container (HotReload) or controller polling (Rollout)
is used to keep the Git content up-to-date.
type: boolean
interval:
description: |-
Interval is the polling interval for checking remote changes.
Default: "5m".
type: string
policy:
default: HotReload
description: |-
Policy determines how changes are applied.
HotReload (default): sidecar pulls changes in-place, no Pod restart.
Rollout: controller detects changes and triggers Deployment rolling update.
enum:
- HotReload
- Rollout
type: string
reload:
description: |-
Reload asks the OpenCode server to re-scan its configuration after a
HotReload update lands, so the change takes effect without a Pod restart.

This matters for content the server snapshots at instance start — most
notably skills, which are discovered once and cached in memory. Updating
files on disk alone is invisible to a running server.

The reload is performed by the git-sync sidecar calling the server's
reload endpoint. To avoid interrupting work in progress, the reload is
deferred while any session is busy and retried on the next sync cycle.

Only effective with Policy: HotReload, and only for long-running Agents
(ignored for ephemeral Task pods).

This field is an opt-in for Git contexts. Skill sources always reload
when sync is enabled, since re-scanning is the point of syncing skills;
set sync on a skill only if you want that behavior.
type: boolean
type: object
required:
- repository
type: object
x-kubernetes-validations:
- message: sync.policy Rollout is not supported for skills;
use HotReload
rule: '!has(self.sync) || !has(self.sync.policy) || self.sync.policy
!= ''Rollout'''
name:
description: |-
Name is a unique identifier for this skill source.
Expand Down
20 changes: 20 additions & 0 deletions charts/kubeopencode/crds/kubeopencode.io_crontasks.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -291,6 +291,26 @@ spec:
- HotReload
- Rollout
type: string
reload:
description: |-
Reload asks the OpenCode server to re-scan its configuration after a
HotReload update lands, so the change takes effect without a Pod restart.

This matters for content the server snapshots at instance start — most
notably skills, which are discovered once and cached in memory. Updating
files on disk alone is invisible to a running server.

The reload is performed by the git-sync sidecar calling the server's
reload endpoint. To avoid interrupting work in progress, the reload is
deferred while any session is busy and retried on the next sync cycle.

Only effective with Policy: HotReload, and only for long-running Agents
(ignored for ephemeral Task pods).

This field is an opt-in for Git contexts. Skill sources always reload
when sync is enabled, since re-scanning is the point of syncing skills;
set sync on a skill only if you want that behavior.
type: boolean
type: object
required:
- repository
Expand Down
Loading
Loading