CI and Release Process

CI and Release Process

---

Workflows Overview

Workflow	File	Triggers
Build & Test	build.yml	Push to main / fix/v3.23-custom, any PR, manual
Dash/POSIX Compatibility	dash-compat.yml	Push to main / fix/v3.23-custom, PR, manual
Release Binaries	release.yml	Push a v* tag, manual
Pre-Release Shakedown	shakedown.yml	Push a v3.23.0-fix.* tag, manual
Shakedown Droplet Sweeper	shakedown-sweeper.yml	Every 15 minutes (schedule), manual
CodeQL Security Scan	codeql.yml	Sunday 22:00 UTC weekly, manual
Upstream Monitor	upstream_monitor.yml	Midnight + noon UTC daily, manual

---

Build & Test (build.yml)

Two jobs run in parallel:

test-and-lint

1. Checks out code with full git history and tags
2. Sets up Go 1.26 with module cache
3. Runs shell installer tests (scripts/test_provider_install.sh)
4. Runs shell fallback logic tests (scripts/test_fallback_logic.sh)
5. Runs Go unit tests across the root and provider/ packages
6. Runs go vet on root and provider/
7. Runs govulncheck (non-blocking — reports CVEs but doesn't fail the build)

build-and-push

1. Sets up QEMU + Docker Buildx for multi-arch
2. Logs into GHCR and Docker Hub
3. Extracts version from tag or most recent git tag
4. Builds and pushes linux/amd64 + linux/arm64 Docker image
   • On PRs: build only, no push
   • On push to main or tag: build + push

Wall-clock time is dominated by the Docker build (~4-8 min with QEMU). The test job runs alongside it and completes first.

---

Dash/POSIX Compatibility (dash-compat.yml)

Guards the Linux installer (scripts/Provider_Install_Linux.sh, aka urnet-tools): it is intended to run under dash via #!/bin/sh. This workflow rejects bashisms in the installer and any published instruction that pipes the installer to bash instead of sh.

---

Release Binaries (release.yml)

Triggered automatically when a v* tag is pushed. Also runnable manually from the Actions tab.

What it does:

1. Builds native provider binaries via a matrix over goos: [linux, darwin, windows] × goarch: [amd64, arm64]
2. Assembles binaries into urnetwork-provider-<version>.tar.gz
3. Checks for a matching release notes file at releases/<version>.md
   • If found: uses it as the GitHub Release body
   • If not found: auto-generates release notes from git log
4. Creates a GitHub Release with the tarball attached
   • Tags containing -rc, -alpha, or -beta are marked pre-release automatically

The release publishes right after the builds finish. It does not wait for malware scanning. VirusTotal and ClamAV scans run afterward, in a separate job that runs in parallel with nothing blocking on it. The scans append their verdict to the release body once done. They never delay or block publication. NOTE: a malware hit is reported loudly in the release body, but it does not unpublish the release.

---

Pre-Release Shakedown (shakedown.yml)

Runs a live droplet test against the freshly tagged release. It waits for the release workflow's own conclusion instead of running on a fixed timer. This keeps the droplet test aligned with the actual release build. If the release build fails, the shakedown fails fast instead of testing a stale or missing artifact.

---

Cutting a Release

1. Write release notes (optional but recommended):

   # Create releases/v3.23.0-fix.29.0.md with your notes

   Keep FORK_CHANGES.md and CHANGELOG.md current in the same PR that lands the code (see the repo's docs workflow). House style (since 2026-08-14): write release notes and PR bodies in STE100 (Simplified Technical English) — short sentences (~8-14 words), active voice, one meaning per word, NOTE:/must markers, no em dashes or metaphor. Always keep the machine-generated What's Changed section with full PR links. Long narrative prose is rejected.

2. Commit everything to main and push:

   git push origin main

3. Tag and push:

   git tag v3.23.0-fix.28.1
   git push origin v3.23.0-fix.28.1

4. GitHub Actions triggers release.yml and build.yml automatically. The Docker image will be tagged with both latest and the version tag. The binary tarball will appear on the Releases page.

Version format: v3.23.0-fix.<N> for stable, v3.23.0-fix.<N>-rc.<M> for release candidates.

---

CodeQL Security Scan (codeql.yml)

Runs a full static analysis of the Go codebase once per week (Sunday nights UTC). Results appear under the Security → Code scanning tab in GitHub.

• Never runs on PRs or pushes — no CI latency impact
• Restricted to the full-bars/urnetwork-3.23-fix repository to avoid wasting Actions minutes on forks
• Can be triggered manually from the Actions tab for an on-demand scan

---

Upstream Monitor (upstream_monitor.yml)

Runs twice daily (midnight and noon UTC) and watches upstream repos for activity that could affect this fork. Sends Discord alerts via DISCORD_WEBHOOK secret.

Six parallel jobs:

Job	What it watches	Alert color
monitor-critical-files	PRs on urnetwork/connect (last 12h) touching critical files (ip.go, transfer.go, etc.)	🔴 Red — requires review
monitor-all-prs	Any PR activity on upstream urnetwork/connect in the last 12h	🔵 Blue — informational
monitor-commits	Commits merged to urnetwork/connect main in the last 12h touching critical files	🟢 Green — shipped upstream
monitor-sibling-drift	Commits to full-bars/connect (the upstream-tracking sibling fork) touching shared critical files — port check	🟠 Orange — port check
monitor-build-releases	New urnetwork/build releases; classifies provider-impact vs client-only	🟡 Yellow — evaluate
monitor-sn-repo	Commits to urfoundation/sn (Bittensor subnet repo that absorbed the old provider code) touching miner/, cli/miner/, cmd/, onchain/, proto, or dependency files — portability assessment	🟠 Orange — port check

Critical files watched on urnetwork/connect: ip.go, transfer.go, transfer_contract_manager.go, transfer_route_manager.go, net_http.go, net_http_doh.go, transport.go, transfer_encrypt.go, provider/main.go, proxy_health.go, message_pool.go

AI-generated diff summaries (red/orange/yellow alerts) use a 3-tier fallback chain: opencode-go gateway first (opencode-go/deepseek-v4-flash via the opencode CLI), then the DeepSeek API (deepseek-v4-flash), then Gemini (gemini-3.1-flash-lite). Each tier is skipped if its API key is unset or the call fails.

Required Secrets

Secret	Required by
GITHUB_TOKEN	All workflows (auto-provided)
DISCORD_WEBHOOK	upstream_monitor.yml
OPENCODE_API_KEY	upstream_monitor.yml (AI summaries — primary tier)
DEEPSEEK_API_KEY	upstream_monitor.yml (AI summaries — fallback tier)
GEMINI_API_KEY	upstream_monitor.yml (AI summaries — final fallback)
DOCKERHUB_USERNAME	build.yml
DOCKERHUB_TOKEN	build.yml