Keep external sync as script-managed automation
Constraint: The maintainer wants periodic upstream sync handled by script logic rather than Gitea workflow automation. Rejected: Repository-owned Gitea Actions schedule | The remote Gitea runner setup is unnecessary for the current direction. Confidence: high Scope-risk: narrow Directive: Treat scripts/sync_external_plugins.ps1 as the synchronization entry point unless a new scheduler is explicitly requested. Tested: python scripts\\validate_marketplace.py; rg found no remaining Gitea Actions sync references. Not-tested: External scheduler/container execution.
This commit is contained in:
@@ -97,15 +97,7 @@ After sync, validate the marketplace:
|
||||
python scripts\validate_marketplace.py
|
||||
```
|
||||
|
||||
`.gitea/workflows/sync-external-skills.yml` is a scheduled workflow prototype for Git-side periodic sync.
|
||||
|
||||
For a Docker-hosted Gitea instance, the workflow file alone is not enough. Gitea must have Actions enabled and an `act_runner` container registered before scheduled jobs will run. The runner that handles this repository should provide:
|
||||
|
||||
- A label matching `runs-on: ubuntu-latest`, or adjust the workflow to your runner label.
|
||||
- `git`, `python`, and `pwsh` in the job environment.
|
||||
- Network access from the job container to GitHub for upstream skill repos and to the Gitea instance for checkout/push.
|
||||
|
||||
If the Gitea server does not have Actions enabled, run the same sync command from a host cron job or a small maintenance container that checks out this repository, runs the sync script, validates, commits, and pushes changes.
|
||||
Periodic sync should call the script directly from a maintenance process, cron job, or service container. Keep the scheduling layer outside this repository; the repository only defines source config, generated plugin output, and validation.
|
||||
|
||||
## Layout
|
||||
|
||||
|
||||
Reference in New Issue
Block a user