zeekayandHanzo Dev
1414fd6ce0
Our own documentation called the product Gitea. It is Hanzo Forge, so it now says so — README family, CONTRIBUTING, docs/, and the per-package READMEs. Three kinds of "Gitea" are not branding, and they stay: - MIT attribution: the copyright header template, the LICENSE, and the "white-label fork of Gitea" statement in each README. - Provenance: modules/git came from go-gitea/git, the Actions token design was proposed upstream in #24635, the base is 1.26.4 of go-gitea/gitea. - Addressing values: /data/gitea and /etc/gitea, the gitea-data PVC, the GITEA__ env prefix, X-Gitea-* headers. LLM.md's inventory of these is unchanged. Links that pointed at upstream infrastructure described a project this fork is not. Contributor issues, security reports and documentation now land here; the Crowdin sync, the GiteaBot backporter, the blog PR and the dl.gitea.com asset checks describe no lane this repo has, and the release section now records the one it does — tag, push to canonical, semver image, universe pin. Four references were dead as written, not merely upstream: - docs/setup.md is docs/build-setup.md - build/backport-locale.go does not exist - .github/workflows does not exist here; the workflows are .hanzo/workflows - the -X ldflags named code.gitea.io/gitea symbols, which this binary has none of, so the linker set nothing. The module path is github.com/hanzoai/git and cmd.PIDFile defaults to /run/gitd.pid. gitea help and gitea completion are gitd. gitea-runner is git-runner. The GitHub repo is hanzoai/forge now, so the clone and fork URLs point there. ghcr.io/hanzoai/git is untouched: a package is not renamed by a repo rename and the running deployment pins that image. The Go module path is untouched for the same reason — go.mod still declares github.com/hanzoai/git. Co-authored-by: Hanzo Dev <[email protected]>
2.6 KiB
Setup and requirements
This document lists the tools you need to build Hanzo Forge from source and how to get the code. Once your environment is ready, see development.md for the build and development workflow, and testing.md for running tests.
For the contribution workflow and review process, see CONTRIBUTING.md.
Requirements
Go
Install Go and set up your Go environment. The
required version is the one declared in go.mod; installing the same
version your continuous integration uses avoids gofmt differences between Go
releases.
Note
Some
maketasks build external Go tools on demand (for examplemake watch-backend). To use them, the"$GOPATH"/bindirectory must be on your executablePATH; otherwise you have to manage those tools yourself.
Node.js and pnpm
Install Node.js to build the JavaScript and CSS
files. The minimum supported version is the one declared in
package.json (engines.node); the latest LTS is recommended.
Hanzo Forge manages frontend dependencies with pnpm. The make
targets invoke it for you, so installing pnpm manually is only needed if you want
to run pnpm commands directly.
Make
Hanzo Forge uses Make to drive builds, linting, and tests. On Windows it can be installed via MSYS2 or Chocolatey.
Python with uv (optional)
Linting the templates, workflow files, and YAML requires Python tooling that Hanzo Forge
runs through uv. After installing uv, make creates
the environment automatically (uv sync); you only need this if you run
make lint-templates, make lint-yaml, or make lint-actions locally.
Git LFS
The integration tests require Git LFS to be installed.
Getting the source code
Clone the repository:
git clone https://github.com/hanzoai/forge
To contribute changes, fork the repository on GitHub and add your fork as a git remote so you can push branches and open pull requests. See GitHub's working with forks documentation for the details.
Installing dependencies
Most build and test targets install the dependencies they need on their own. To
fetch everything up front, run make deps (or the per-group make deps-frontend,
make deps-backend, make deps-tools, make deps-py).