- Go 54.7%
- JavaScript 29.5%
- CSS 10.9%
- HTML 3.1%
- Shell 1.1%
- Other 0.7%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
harbor-bot
ff614d6d40
All checks were successful
Deploy control to staging / Deploy (push) Successful in 1m10s
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [golang](https://hub.docker.com/_/golang) ([source](https://github.com/docker-library/golang)) | stage | minor | `1.25-alpine` → `1.27-alpine` | --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - "before 9am on tuesday" - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC4xMzMuMCIsInVwZGF0ZWRJblZlciI6IjQ0LjEzMy4wIiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIiwibGFiZWxzIjpbImRlcGVuZGVuY2llcyIsInJlbm92YXRlIl19--> Reviewed-on: #6 |
||
| .forgejo | ||
| deploy/charts/harbor-control | ||
| static | ||
| .dockerignore | ||
| .editorconfig | ||
| .env.example | ||
| .gitignore | ||
| board.go | ||
| board_test.go | ||
| config.go | ||
| deploys.go | ||
| deploys_test.go | ||
| Dockerfile | ||
| dotenv.go | ||
| forgejo.go | ||
| go.mod | ||
| main.go | ||
| milestones.go | ||
| milestones_test.go | ||
| poker.go | ||
| poker_test.go | ||
| README.md | ||
| renovate.json | ||
| retro.go | ||
| retro_test.go | ||
| session.go | ||
Harbor Control
The Harbor team's operations page over Forgejo at control.harbor.social:
a GitLab-style issue board whose columns are Status/* labels, live planning
poker that writes the agreed Weight/N label, a retro board that sorts a
sprint's issues into Retro / * labels, burndown and burnup charts per
milestone weighted by those weights, and the deploy state of every service
with a button for production deploys. Users sign in with Forgejo OAuth2 and
everything is done as them, so permissions and attribution stay Forgejo's. It
is a single Go binary with no dependencies; the only state it keeps is the
poker rooms, in memory, so a restart costs at most a round of voting.
Planning and retro
Planning (/planning/<milestone>) is one live poker table for the team,
meant to sit beside the planning call: everyone who opens the page is in the
room. The queue lists the chosen milestone's open issues from the board,
those without a weight first; picking one puts it on the table for everyone
and pulls their queues to that milestone. Votes are face down until someone
reveals, then anyone can write a value as the issue's Weight/N label. The deck is HARBOR_CONTROL_POKER_DECK
(default 1,2,3,5,8,13,21,?); only numbers become labels. The browser holds
a Server-Sent Events stream, so the ingress must not buffer text/event-stream.
Retro (/retro/<milestone>) shows every issue in the milestone, open or
closed, with a column for each label in the HARBOR_CONTROL_RETRO_SCOPE
scope (default Retro, so Retro / Spot-On and friends) found in the org's
repos. Dragging a card adds that label and removes any other retro label,
leaving status and everything else alone; the filter defaults to your own
issues. Add a label on Forgejo and it becomes a column.
Running locally
Register a personal OAuth2 application on code.futo.org (Settings,
Applications) with redirect URI http://localhost:8080/auth/callback, copy
.env.example to .env, fill in the client id and secret and a random
session secret, then:
go run .
The binary reads .env from its working directory; docker build -t control . && docker run --rm -p 8080:8080 --env-file .env control runs the image the
same way. Moves on the board relabel real issues as you, so set
HARBOR_CONTROL_REPOS to one repo while trying things out.
Deploying
Every push to master runs deploy-control-staging, which builds and signs
the image, publishes the chart to registry.futo.org/harbor/charts/harbor-control
with the commit as appVersion, and moves the staging tag.
deploy-control-production moves staging, or a given commit, to
production. The clusters follow those tags through Flux, and the OAuth2
client, the vault item and the HTTPRoute live in
harbor-infra, see its docs/10.
Layout
.
├── *.go # server: OAuth2 session, board, retro, poker, milestones, deploys
├── static/ # the page, vanilla JS, Harbor palette
├── deploy/charts/harbor-control/
├── .forgejo/workflows/ # pr, deploy-control-staging, deploy-control-production
└── .forgejo/scripts/cosign-sign.sh