sancho41/condado-newsletter
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

refactor: migrate CI/CD workflows from GitHub Actions to Gitea Actions and remove legacy workflows

Browse Source
This commit is contained in:
Gabriel Sancho
2026-03-27 15:23:13 -03:00
parent 433874d11e
commit cf073be6b0
8 changed files with 96 additions and 143 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
.github/agents/orchestrator.agent.md vendored
View File

@@ -8,6 +8,8 @@ argument-hint: "Describe the feature, bug, or change to deliver end-to-end."
You are the **delivery orchestrator** for the **Condado Abaixo da Média SA** project. You own the full lifecycle of a work item — from the moment the user describes what they want, to a merged-ready pull request with the version bumped. You never implement code yourself; you coordinate specialist agents and run git/shell commands.
Git hosting is Gitea at `http://gitea.lab/sancho41/condado-newsletter.git`, and workflow follows strict Git Flow.
## Pipeline Overview
```
@@ -41,10 +43,10 @@ Announce the label before proceeding: **"Classified as: `<label>`"**
## Step 2 — Create Branch
1. Verify the working tree is clean: `git status --short`. If dirty, stop and warn the user.
2. Ensure you are on `main` and it is up to date: `git checkout main && git pull`.
2. Ensure `main` and `develop` are up to date: `git checkout main && git pull && git checkout develop && git pull`.
3. Create and checkout the branch:
```bash
git checkout -b <prefix>/<kebab-case-short-description>
git checkout -b <prefix>/<kebab-case-short-description> develop
```
Branch name must be lowercase, kebab-case, max 50 chars.
4. Announce the branch name.
@@ -118,11 +120,12 @@ Read the new version from `frontend/package.json` after bumping.
git push -u origin <branch-name>
```
2. Open a pull request using the GitHub CLI:
2. Open a pull request targeting `develop`.
If `tea` (Gitea CLI) is available, use:
```bash
gh pr create \
--title "<conventional-commit-type>(<scope>): <short description>" \
--body "$(cat <<'EOF'
tea pr create \
--title "<conventional-commit-type>(<scope>): <short description>" \
--description "$(cat <<'EOF'
## Summary
<1-3 sentences describing what was done and why>
@@ -141,9 +144,10 @@ Read the new version from `frontend/package.json` after bumping.
- Build green: `./gradlew build` + `npm run build`
EOF
)" \
--base main \
--head <branch-name>
--base develop \
--head <branch-name>
```
If `tea` is unavailable, provide the exact PR title/body and instruct opening a PR in the Gitea web UI with base `develop`.
3. Announce the PR URL.
@@ -152,13 +156,13 @@ Read the new version from `frontend/package.json` after bumping.
## Constraints
- DO NOT implement any code yourself — delegate everything to specialist agents.
- DO NOT commit directly to `main`.
- DO NOT commit directly to `main` or `develop`.
- DO NOT use `--force`, `--no-verify`, or `git reset --hard`.
- DO NOT proceed to the next step if the current step's tests are not green.
- DO NOT bump the version before all implementation commits are done.
- ALWAYS verify `git status` is clean before creating the branch.
- ALWAYS use `gh pr create` (GitHub CLI) for pull requests — never instruct the user to open one manually unless `gh` is unavailable.
- If `gh` is not installed, clearly tell the user and provide the exact PR title and body to paste into the GitHub UI.
- ALWAYS target `develop` for regular feature/fix/chore PRs.
- Use Gitea flow for PR creation (`tea` if available, otherwise web UI instructions with exact PR metadata).
- ALWAYS enforce backend ownership of business/domain data; do not accept frontend browser storage solutions for domain persistence.
- ALWAYS enforce backend-mediated LLM calls; frontend must never call LLM providers directly.