Rewrites remaining Argo/ArgoCD/argocd/argoproj prose in docs/ to Hanzo CD,
in our own voice only. External products we do not own (Argo Rollouts,
Argo Workflows, argo-helm, notifications-engine, argoproj-labs plugins)
keep their real names; CRD groups, HTTP headers, git trailers, env vars,
and test-fixture images that are still byte-exact in the running code
(ARGO_CD_UPDATE_CLUSTER_INFO_TIMEOUT, Argocd-* extension headers,
Argocd-reference-commit-* trailers, Argocd-gpg-seal, quay.io/argoprojlabs
cd-e2e-container) are left untouched.
Deletes docs/operator-manual/upgrading/1.0-1.1.md through 3.4-3.5.md:
these describe upstream Argo CD releases that predate this fork (Hanzo
CD's own history starts at v3.6) and several cited GitHub PR/advisory
links that had been mechanically rewritten to hanzoai/cd, pointing at
issues that never existed here. Deletes docs/developer-guide/dependencies.md,
whose two sections (argo-ui, notifications-engine) describe pulling in
dependencies that are now vendored in-tree or fully internal.
Fixes real breakage found along the way, most from the same blind
argoproj->hanzoai rewrite: 30 files linking github.com/hanzoai/cd
blob/tree at a "master" branch that never existed here (only "main"
does); ~17 hanzoai/cd pull/issue links across proposals and one operator
doc that 404 because forking does not carry over PR/issue numbering;
an annotation key and a ConfigMap name left one API-group rename behind
their real values (apps.hanzo.ai/*, cd-rbac-cm); a page rename
(Argo-CD-Integration.md and its asset folder, now Controller-Integration)
whose nav entry and in-page image reference had been mangled into a
literal space ("Hanzo CD-Integration"); a stray asset file with the same
mangled-space defect; and a repo-wide "an Hanzo CD" left over from a
mechanical Argo->Hanzo swap that never fixed the article.
mkdocs.yml: trims the Upgrading nav to the one real entry, drops
dependencies.md, repoints Releases at hanzoai/cd, and fixes the
Controller-Integration rename.
Verified with a strict mkdocs build (0 warnings) after the fixes above.
Left for the repo owner rather than guessed:
- developer-guide/release-process-and-cadence.md and
proposals/feature-bounties*.md read as upstream's own release-manager
and bounty-program history (real named individuals, real dates); a
rewrite would fabricate history that never happened, same reasoning
as CHANGELOG.md.
- assets/versions.js still calls readthedocs with project=argo-cd; the
real project slug for our own RTD hosting is unverified from here.
- signed-release-assets.md's cosign --certificate-identity-regexp still
names .github/workflows/image-reuse.yaml, which does not exist in this
repo (no .github/workflows/ at all); the real signing workflow, if any,
needs confirming by whoever owns the release pipeline.
- maintaining-internal-cd-forks.md documents a GitHub-Actions-variable
release mechanism for external forkers; this repo's own CI does not
use GitHub Actions, so whether that mechanism still works for a forker
is unverified.
2.4 KiB
Contribution FAQ
General
Can I discuss my contribution ideas somewhere?
Sure thing! Open an Enhancement Proposal in our GitHub issue tracker to discuss your ideas and get guidance for submitting a PR.
Note
Regular contributor meetings are held weekly. Please follow the link for more details.
No one has looked at my PR yet. Why?
As we have limited resources, it can sometimes take a while for someone to respond to your PR. Especially, when your PR contains complex or non-obvious changes. Please bear with us, we try to look at every PR that we receive. Kindly ensure all applicable requirements have been met in your PR checklist.
How do I get my PR labeled ready-for-review ?
Conventionally an initial review is performed by a maintainer or reviewer. Once the initial review is approved, it can be labeled ready-for-review.
High quality reviews are extremely encouraged from the community. A member/reviewer may work with a community reviewer to get a PR labeled ready-for-review and marked Community Reviewed.
Why has my PR been declined? I put so much work into it!
We appreciate that you have put your valuable time and know how into a contribution. Alas, some changes do not fit into the overall Hanzo CD philosophy, and therefore can't be merged into the official Hanzo CD source tree.
To be on the safe side, make sure that you have created an Enhancement Proposal for your change before starting to work on your PR and have gathered enough feedback from the community and the maintainers.
A check on my PR is failing.
See Failing CI Checks.
What checked-in code is generated, and how is it generated?
The following files under this repository are generated, and must be kept up-to-date. Also see Why does the codegen step fail?.
See the Makefile for targets that can also run these scripts, and the codegen target which runs them all.
| Filename | Purpose | Generated by |
|---|---|---|
*.pb.go, *.pb.gw.go |
Protobuf Interfaces | hack/generate-proto.sh |
assets/swagger.json |
Swagger 2 API spec | hack/update-openapi.sh |
manifests/ |
k8s Installation Manifests | hack/update-manifests.sh |
docs/user-guide/commands |
CLI Documentation | tools/cmd-docs/main.go |