Developer Quickstart
Your repositories are moving from GitHub to our self-hosted Gitea instance at git.progroupco.com. This guide gets you set up in under 10 minutes.
0 What's Different
URL
From github.com to git.progroupco.com
Organization
All repos live under ProGroup CI (slug: ci)
Authentication
HTTPS tokens (not SSH keys). Entra ID SSO for the web UI.
Token-basedCI / CD
Gitea Actions — same YAML syntax as GitHub Actions. AI workflows included.
Drop-in compatible.gitea/workflows/ YAML files
are fully compatible with GitHub Actions syntax.
1 Web Login
- Go to https://git.progroupco.com
- Click "Sign in with entra" (Microsoft SSO)
- Authenticate with your ProGroup Entra credentials (MFA handled by Entra)
git push.
2 Create a Personal Access Token
Git clone/push via HTTPS uses a Gitea access token (separate from your Entra credentials). Treat it like a password.
- Go to Settings → Applications → Access Tokens (top-right avatar → Settings)
- Click Generate New Token
- Name it (e.g.,
git-push) - Select scope: read:repository + write:repository
- Copy the token immediately (shown only once)
read:repository lets you clone/fetch from any repo you can see.
write:repository lets you push to any repo where you have write access.
This pair is the minimum for normal development. Never share your personal token in
CI configs — use the org-level secrets described in Secrets.
3 Configure Git Credential Caching
So you only enter the token once per machine, configure Git to remember your credentials:
# Option A: Store permanently (creates ~/.git-credentials):
git config --global credential.helper store
# Option B: Cache in memory for 1 hour (more secure):
git config --global credential.helper 'cache --timeout=3600'
Git for Windows includes Git Credential Manager (GCM), which stores credentials in the Windows Credential Store automatically:
# GCM is the default in Git for Windows. If it's not active, enable it:
git config --global credential.helper manager
# If you need the older wincred helper:
git config --global credential.helper wincred
git:.
4 Clone Your Repo
All company repos live under the ProGroup CI organization (URL slug: ci). Replace your-repo with your actual repository name.
git clone https://git.progroupco.com/ci/your-repo.git
cd your-repo
# Username: lowercase part of your email before the @ (e.g., mchildress)
# Password: paste the token from Step 2
git clone https://git.progroupco.com/ci/your-repo.git
cd your-repo
# If using Git Credential Manager, a popup appears:
# Username: lowercase part of your email before the @
# Password: paste the token from Step 2
5 Update Existing Local Clones
If you already have a local clone pointing at GitHub, repoint it to Gitea:
cd ~/projects/your-repo
git remote set-url origin https://git.progroupco.com/ci/your-repo.git
git fetch origin
git branch --set-upstream-to=origin/main main
# If your default branch is 'master':
# git branch --set-upstream-to=origin/master master
cd C:\Users\you\projects\your-repo
git remote set-url origin https://git.progroupco.com/ci/your-repo.git
git fetch origin
git branch --set-upstream-to=origin/main main
# If your default branch is 'master':
# git branch --set-upstream-to=origin/master master
Branch Naming (Critical)
feature/** and chore/** branches.
Pushing to fix-bug, wip, or any other prefix gets no CI at all —
no lint fixes, no test generation, no Docker builds. PR-triggered workflows (review,
coverage, pr-summary) fire on any PR regardless of branch name.
| Branch pattern | What fires on push | What fires on PR |
|---|---|---|
feature/** | lint-fix, generate-tests, api-docs, build-docker, review | All PR workflows |
chore/** | lint-fix, generate-tests, api-docs, build-docker | All PR workflows |
main / master | build-docker (tags :latest) | — |
v* tag | changelog | — |
| anything else | nothing | All PR workflows |
# Correct: prefix with feature/ or chore/
git checkout -b feature/add-login
git checkout -b chore/update-deps
# Wrong: no prefix — CI will NOT run on push
git checkout -b fix-bug # no CI
git checkout -b my-experiment # no CI
Your First Pull Request
How a typical feature goes from branch to merged PR:
- Branch:
git checkout -b feature/your-featurefrommain - Commit & push:
git push origin feature/your-feature— this triggers lint-fix and generate-tests on the branch. If lint fixes are needed, the bot auto-commits them. - Open a PR in the Gitea UI (repo → Pull Requests → New). Target
mainas the base. - Wait ~1–2 minutes. The following fire automatically on the PR:
- review AI posts a structured code review comment with severity tags
- coverage Diff coverage report posted as a comment
- pr-summary Human-readable summary of what the PR does
- commit-message Suggested conventional commit message
- labeler Labels applied based on changed file paths
- Address any
high-severity findings from the review — these fail the check and block merge. Push fixes to the same branch; the review re-runs on synchronize. - Merge when the check is green. On merge (push to
main), build-docker fires and tags:latestif the repo has a Dockerfile.
[skip ci]. The auto-generated tests and lint fixes won't re-trigger CI loops — the actor check plus the skip flag prevents infinite runs.Troubleshooting
| Symptom | Where to check | Likely fix |
|---|---|---|
| CI didn't run on my push | Branch name | Use feature/** or chore/** — see Branch Naming |
401 on git push | Token scope | Regenerate token with write:repository scope; clear cached creds (see FAQ) |
Review says high severity | PR review comment | Fix the flagged lines, push to the same branch — review re-runs on synchronize |
| Bot didn't commit tests | Actions tab → generate-tests run log | Check scan_mode — diff only scans changed files; all scans the whole repo |
| Workflow not in Actions tab | Branch the workflow was pushed to | Workflows only activate from the default branch (main) — push the YAML there first |
| Docker build failed | Actions tab → build-docker run log | Check Kaniko error; if AI-generated Dockerfile is wrong, edit it and re-push |
| PR has no review comment | Actions tab → review run status | If the run failed, check the log for API key errors; review only posts on success |
Creating a New Repository
ci), not under your personal account. Repos under ci automatically inherit the shared CI secrets (NEURALWATT_API_KEY, REVIEW_TOKEN, BOT_TOKEN, PACKAGES_TOKEN). Personal repos will fail silently — workflows that depend on these secrets won't find them.- Go to https://git.progroupco.com/ci
- Click New Repository (top-right of the org page)
- Set the name and visibility (Private recommended)
- Check "Use template" → select
ci/ci-template— copies the full CI workflow set (workflows, scripts, prompts) into your new repo automatically - Click Create Repository
- Clone it as described in Step 4
Migrating an existing repo from GitHub
Ask your admin to run the migration script, which:
- Migrates Git history (no issues/PRs/wiki — those stay on GitHub)
- Overlays
.gitea/fromci/ci-template(workflows + scripts) - Commits + pushes the CI template files
- Triggers an initial code review + test generation
Or migrate manually:
# Clone from GitHub (bare — preserves all branches + tags)
git clone --mirror https://github.com/yourorg/your-repo.git
cd your-repo.git
# Push everything to Gitea
git push --mirror https://git.progroupco.com/ci/your-repo.git
# Then overlay .gitea/ from ci/ci-template (ask admin)
Secrets
Org-level secrets (managed by admin)
These are set at the ProGroup CI organization level and inherited by every repo under ci/. They're injected into workflow jobs automatically — no per-repo configuration needed.
| Secret | API Scope | Used By | What It Does |
|---|---|---|---|
NEURALWATT_API_KEY |
LLM provider | review, generate-tests, docs, api-docs, changelog, pr-summary, commit-message, secure-scan, build-docker | API key for the neuralwatt/glm-5.2 model used by all AI workflows |
REVIEW_TOKEN |
write:issue |
review, coverage, pr-summary, commit-message, labeler, stale, secure-scan | Posts PR comments, applies labels, manages stale issues |
BOT_TOKEN |
write:repository |
generate-tests, lint-fix, docs, api-docs, build-docker, changelog, dep-update | Pushes auto-generated commits (tests, docs, Dockerfiles, dep bumps) |
PACKAGES_TOKEN |
write:package |
build-docker | Pushes built Docker images to the Gitea container registry |
*** in action run output.Repo-level secrets (when you need your own)
If a workflow needs a secret specific to your repo (e.g., a third-party API key, a deployment token):
- Go to your repo → Settings → Actions → Secrets
- Click Add Secret
- Name it (uppercase, underscores: e.g.,
DEPLOY_TOKEN) - Paste the value, click Add Secret
Repo-level secrets override org-level secrets with the same name. Reference them in workflow YAML with ${{ secrets.YOUR_SECRET }}.
.env files. Gitea only injects secret values into CI job environments; they are not visible in the repo, PRs, or the web UI after creation.Workflows
All workflows live in .gitea/workflows/ and are included automatically when your repo is created from the CI template.
🟦 Pull Request Workflows
These fire when a PR is opened or updated:
AI code review on the diff. Posts a structured comment with severity-tagged findings. Fails the run on high-severity issues. Also fires on pushes to feature/**.
→ PR comment
Detects source files without tests, generates pytest/jest/vitest tests via AI, runs them, and commits passing tests back to your branch.
→ New commits on the branch + Actions tab
Computes diff coverage (which changed lines lack test coverage) and posts a comment with uncovered file:line ranges.
→ PR comment
Generates a human-readable summary of what the PR does (for reviewers).
→ PR comment
Suggests a conventional commit message based on the PR diff.
→ PR comment
Auto-labels PRs based on changed file paths. Configure rules in .gitea/labeler.yml.
→ PR labels
🟩 Push Workflows
These fire on pushes to feature/** or chore/** branches:
Runs ruff (Python), prettier (JS/TS), gofmt (Go) on changed files. Auto-commits formatting fixes if needed.
→ New commits on the branch
Builds a Docker image and pushes it to the Gitea container registry. If no Dockerfile exists, AI generates one and opens a PR. On main/master, also tags :latest.
→ PR (if Dockerfile generated) + docker pull git.progroupco.com/ci/your-repo:<sha>
Generates API documentation from source code analysis.
→ Commits on docs/auto-update branch + PR
Generates/updates general project documentation (README, usage docs) from source. Manual dispatch only.
→ Commits on docs/auto-update branch + PR
🟨 Scheduled Workflows
Marks PRs and issues with no activity for 30+ days as stale, closes them after 7 more days of inactivity.
→ Stale label on PRs/issues + Actions tab
Bumps dependency versions in your manifest files (package.json, requirements.txt, go.mod, etc.) and opens a PR.
→ PR on dep/auto-update branch
Scans the repo for exposed secrets, hardcoded credentials, and security anti-patterns using AI. Fails on high-severity findings.
→ Actions tab (summary with findings)
🟪 Tag-Triggered Workflows
Generates a CHANGELOG.md section from git log entries since the last tag. Commits to a changelog/auto-update branch and opens a PR.
→ PR on changelog/auto-update branch
Manually Triggering a Workflow
Many workflows can be triggered manually from the Gitea UI:
- Go to your repo → Actions tab
- Click the workflow name (e.g.,
opencode-review) - Click Run Workflow (top-right of the run list)
- Select the branch and fill in any inputs
- Click Run
Dispatch Inputs Reference
| Workflow | Input | Type | Description |
|---|---|---|---|
review | scan_mode | select: all / diff | all reviews the entire repo; diff reviews changed files only |
generate-tests | scan_mode | select: all / diff | all scans entire repo for untested files; diff scans changed files only |
lint-fix | scan_mode | select: all / diff | all formats every tracked source file; diff formats changed files only |
secure-scan | fail_on_high | boolean (default: true) | If true, the run fails on high-severity findings |
dep-update | manifest | string | Specific manifest path to bump (default: all) |
dep-update | allow_major | boolean (default: false) | If true, bumps major versions (breaking changes allowed) |
changelog | version | string | Version label for the changelog section (e.g., 1.2.0) |
build-docker | dockerfile_path | string (default: Dockerfile) | Path to an existing Dockerfile (skip generation) |
build-docker | image_name | string | Custom image name (defaults to repo name) |
commit-message | pr_number | integer (required) | PR number to suggest a commit message for |
coverage | pr_number | integer (required) | PR number to compute coverage for |
pr-summary | pr_number | integer (required) | PR number to summarize |
labeler | pr_number | integer (required) | PR number to label |
docs | — | — | No inputs (runs against the current branch) |
stale | — | — | No inputs (runs a stale check sweep) |
api-docs | — | — | No inputs (runs against the current branch) |
Checking Workflow Results
PR Comments
review, coverage, pr-summary, commit-message posts as comments
PR Labels
labeler applies labels to the PR
Auto-Commits
generate-tests, lint-fix push commits to your branch
Auto-PRs
docs, api-docs, changelog, dep-update, build-docker open PRs
FAQ
When you click "Sign in with entra" for the first time, Gitea looks up your email from the Entra ID token. If an account was pre-provisioned for you (admins were created ahead of time), Gitea links your Entra identity to it — your existing permissions carry over automatically. If no account exists, Gitea creates one with default (non-admin) privileges.
After the first login, subsequent logins are instant — no re-linking needed.
No — SSH (port 2222) is not exposed externally. All Git operations use HTTPS. Your token replaces the SSH key. This is a deliberate security decision — HTTPS tokens are scope-limited and individually revocable, unlike SSH keys which grant full repo access.
LFS is supported. Push as normal — Caddy accepts up to 512MB per request.
Your token may have expired or lacks write:repository scope. Generate a new one (Step 2) and clear the cached credentials:
Linux / macOS
# If using credential.helper store:
rm ~/.git-credentials
# Or clear the cache:
git credential reject <<EOF
protocol=https
host=git.progroupco.com
EOF
Windows
# Delete the stored credential via Credential Manager:
cmdkey /delete:git:https://git.progroupco.com
# Or open the GUI:
# Control Panel → Credential Manager → Windows Credentials
# Find "git:https://git.progroupco.com" → Remove
Next git push will prompt for username + new token.
Go to https://git.progroupco.com/ci → New Repository. Always create repos under the ProGroup CI org (slug: ci) so they inherit the shared CI secrets. If you create a repo under your personal account, org-level secrets resolve to empty strings — workflows that depend on them will print an explicit error in the Actions tab and skip the affected step.
Tip: Check "Use template" → select ci/ci-template to copy the full CI workflow set into your new repo automatically.
At the ProGroup CI organization level (ci org → Settings → Actions → Secrets). The four org-level secrets (NEURALWATT_API_KEY, REVIEW_TOKEN, BOT_TOKEN, PACKAGES_TOKEN) are managed by the admin. They're injected into every workflow job in every repo under ci/ automatically.
For repo-specific secrets (e.g., a third-party deploy token), add them under your repo → Settings → Actions → Secrets.
Linux: git (pre-installed on most distros). Optionally python3 and pytest if you want to run tests locally.
Windows: Git for Windows — includes Git, Git Bash, and Git Credential Manager. Optionally Python 3 for running tests locally.
Yes. Automated commits are authored by the opencode-bot user and carry [skip ci] in the commit message. Workflows also check gitea.actor != 'opencode-bot' so the bot's own pushes never re-trigger CI. You'll never see an infinite loop.
Workflows that auto-commit: generate-tests (adds test files), lint-fix (formats code), and dep-update (bumps dependencies on a PR branch).
Create a .gitea/workflows/your-workflow.yaml file in your repo. The syntax is the same as GitHub Actions. Use the existing workflows as examples. Once pushed to the default branch, the workflow is active.
Need Help?
Operator Docs
.gitea/stack/README.md in the ci/ci-template repo
CI Template
Admin Contact
Contact your infrastructure team