Harbor 开源贡献指南从 Fork 到合入的完整实战流程【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor本篇指南围绕 Harbor 云原生镜像仓库项目的社区贡献规范展开系统梳理了从环境搭建、代码获取、分支管理、开发测试到提交 PR 的完整流程并结合仓库内 Makefile、src/.mockery.yaml 等源码级证据帮助读者理解 Harbor 的代码库结构、Make 驱动开发工作流、controller/manager/dao编程模型与双层 CI 校验机制。读完本文你将掌握向 Harbor 提交高质量代码与提案的完整方法也能对照源码快速定位各功能模块的所在位置。Harbor 社区协作生态概览Harbor 以开放方式开发由用户、贡献者与维护者共同持续改进。作为 CNCF 托管的云原生镜像仓库它的贡献者除了使用 GitHub issue tracker 外还可以通过以下渠道协作双周公开社区会议以及过往会议的录像回放CNCF Slack 上的#harbor终端用户讨论与#harbor-dev开发讨论频道harbor-users与harbor-dev两个邮件列表分别用于用户交流与开发讨论。起步Fork 与本地环境准备Fork 仓库在 GitHub 上将 Harbor 仓库 Fork 到个人账户后按 Go 的 workspace 约定把代码放到GOPATH下。文档给出的标准流程如下# 设置 golang 环境 export GOPATH$HOME/go mkdir -p $GOPATH/src/github.com/goharbor # 获取代码 cd $GOPATH/src/github.com/goharbor/harbor git clone gitgithub.com:goharbor/harbor.git # 将远端重命名为 goharbor并添加自己的 fork git config push.default nothing # 避免默认推送到 goharbor/harbor git remote rename origin goharbor git remote add $USER gitgithub.com:$USER/harbor.git git fetch $USER其中GOPATH可以是任意目录示例使用$HOME/go$USER需替换为你的 GitHub 用户名。git config push.default nothing是一道安全措施防止误把本地提交推到上游。构建项目构建与编译流程可参考 Harbor 官方编译指南从仓库内的 Makefile 可以看到make install实际串联了compile build prepare start四个阶段而make顶层目标依次完成环境准备、编译二进制、构建镜像与安装镜像。仓库结构快速定位代码Harbor 顶层目录的组织方式如下. ├── contrib # 社区贡献的文档、脚本等辅助内容 ├── make # 构建与搭建 Harbor 环境所需的资源 ├── src # 源码目录主要工作目录 ├── tests # API 测试与 e2e 测试用例 └── tools # 支撑工具src是你日常开发的主战场其关键子目录对应关系为目录职责src/cmd含 DB 升级迁移脚本等入口如 standalone-db-migratorsrc/common通用组件如 dao、models、rbac、secret、security 等src/controllerAPI handler 使用的控制器层覆盖 artifact、project、scan、replication 等业务src/core核心业务逻辑含 REST API 与各类服务src/jobservice任务服务组件job、logger、period、worker 等src/portalHarbor Web UI 代码src/registryctl处理 registry 管理逻辑的控制器src/serverAPI 层含 v2.0 handler 等src/testing测试相关工具与 mock 生成物从src/go.mod可以看到模块名为github.com/goharbor/harbor/srcGo 版本要求为 1.26.4与实际构建时使用的GOBUILDIMAGEgolang:1.26.4见 Makefile一致。开发环境搭建Go 与 Web 双栈Go 后端环境Harbor 后端使用 Go 编写不同版本对 Go 版本有明确要求。文档给出从 1.1 到 2.16 的完整对应表这里摘录近期关键版本Harbor要求 Go2.101.21.82.111.22.32.121.23.22.131.23.82.141.24.62.151.26.42.161.26.4当前仓库版本src/portal/package.json 标注 2.15.0对应 Go 1.26.4。搭建环境时需确保GOPATH与PATH按 Go 环境说明正确配置。Web 前端环境Harbor Web UI 基于 Clarity 与 Angular 框架构建需要先安装 npm。仓库当前实际使用的 Angular 为 21.x见 src/portal/package.json。文档给出的历史版本对应关系节选如下Harbor要求 Angular要求 Clarity1.87.1.31.0.01.97.1.31.0.02.08.2.02.3.82.18.2.02.3.82.210.1.24.0.22.310.1.24.0.22.412.0.35.3.0贡献工作流分支、开发与同步PR 始终欢迎即使只是修正拼写或几行代码的小改动。但若有较大改动建议先开 issue 展开讨论再动手实现同时提倡以小步快跑的方式拆分 PR——一个包含大量特性与改动的巨型 PR 很难评审。注意拆分后的每个小改动合入main时都不能破坏现有功能否则该 PR 在该特性完成前无法合并。分支规范改动应在自己 fork 的新分支上进行分支命名为XXX-descriptionXXX为 issue 编号。PR 应基于mainrebase且不要混入多个分支的内容。当 PR 无法干净合并时按以下步骤保持同步# goharbor 是上游 origin cd $working_dir/harbor git fetch goharbor git checkout main git rebase goharbor/main从更新后的main切出新分支git checkout -b my_feature main开发与同步上游编码风格遵循 Golang 社区建议代码与 Markdown 文档的行宽尽量控制在 120 字符以内。项目强制 golint 标准提交前应在源码上运行 golint若报出问题优先按 lint 建议修正代码golint 依据 Effective Go 与 CodeReviewComments 给出建议# 安装 fgt 和 golint go install golang.org/x/lint/golintlatest go install github.com/GeertJohan/fgtlatest # 在 $working_dir/harbor 下执行 go list ./... | grep -v -E tests | xargs -L1 fgt golint分支与goharbor/main失步时使用fetch / rebase而非git pullgit pull会产生合并提交污染提交历史违背每个提交应当独立可理解、有用的原则。也可通过git config branch.autoSetupRebase always改变git pull的行为。推荐的 Make 命令工作流Harbor 提供了一套 Makefile 驱动的开发工作流。对照 Makefile 源码常用命令及其底层行为如下测试与校验make go_check # 运行测试、API 生成、lint、vet、race、拼写检查从 Makefile 可见go_check实际串联了gen_apis mocks_check misspell commentfmt lint其中gen_apis用 go-swagger 从 api/v2.0/swagger.yaml 生成 API servermocks_check通过 src/.mockery.yaml 重新生成 mock 后比对 git status确保 mock 未过期misspell检查 Go 文件拼写错误commentfmt检查//与注释正文之间是否缺少空格lint在src/下执行 golangci-lint超时 10 分钟。构建指定服务make compile_core # 构建 core 服务二进制 make compile_jobservice # 构建 jobservice 二进制后台任务 make compile_registryctl # 构建 registryctl 二进制registry 管理从 Makefile 看这三个目标都是在golang:1.26.4容器内交叉编译产物分别输出到make/photon/core/harbor_core、make/photon/jobservice/harbor_jobservice、make/photon/registryctl/harbor_registryctl。此外还有compile_standalone_db_migrator产物migrate与compile一次性串联 core、jobservice、registryctl 三个编译目标。TLS 证书生成与清理make gen_tls # 仅生成 TLS 证书 make cleanall # 移除所有二进制、镜像与生成的配置 make cleanbinary # 仅移除编译产物 make cleanimage # 仅移除构建的 Docker 镜像 make cleanconfig # 仅移除生成的配置文件cleanall由cleanbinary cleanimage cleanbaseimage cleandockercomposefile cleanconfig cleanpackage聚合而成见 Makefile。构建环境中还可用make check_environment调用 make/checkenv.sh 一键校验 golang、docker、docker-compose 是否就绪。测试后端与前端双框架提交 PR 前应确保改动经过充分测试。Harbor 对后端与前端使用不同的测试框架后端Go服务使用 Go 内置的go testing框架Web UIAngular/Clarity使用 Jasmine 与 Karma。运行单元测试新增代码应配套单元测试。Go 测试命令# cd $working_dir/src/[package] go test -v ./...UI 库测试命令# cd $working_dir/src/portal/lib npm run test从 src/portal/package.json 可见前端测试实际执行ng test --code-coverage另有test:headless无头 Chrome、test:watch等变体可用于不同场景。后端编程模型与 mock 生成Harbor 现在采用controller/manager/dao编程模型建议使用 testify mock 测试controller与manager。项目集成了 mockery 基于 testify mock 包为 Go 接口生成 mock先在src/.mockery.yaml中添加 mock 配置然后运行make gen_mocks生成 mock。查看 src/.mockery.yaml 可以看到配置覆盖了 controller 层artifact、project、scan、replication、robot、retention 等、jobservice 层mgt、period、common/lib 层cache、orm、config与 pkg 层task、user、oidc、rbac 等的数百个接口mock 默认输出到testing/对应目录例如testing/controller/artifact、testing/pkg/scan。提交前make go_check中的mocks_check会校验这些生成的 mock 文件是否与最新接口保持一致。新增或修改 API 的正确姿势从 v2.0 起Harbor 使用 go-swagger 从 Swagger 2.0OpenAPI 2.0规范生成 API server。若要新增或修改 API流程是先更新api/v2.0/swagger.yaml文件运行make gen_apis生成 API server 代码最后在src/server/v2.0/handler包中实现或更新对应的 API handler。从 Makefile 的gen_apis目标可见它会基于api/v2.0/swagger.yaml重新生成src/server/v2.0下的models与restapi再执行 go-swagger 的generate server。当前 src/server/v2.0/handler 下已存在 80 余个 handler 文件覆盖 artifact、auditlog、config、gc、immutable、ldap、member、oidc、project、purge、quota、registry、replication、repository、retention、robot、scan、scanner、schedule、search、security、systeminfo、user、usergroup、webhook 等全部核心 API。提交与 DCO 签名Harbor 集成了 DCODeveloper Certificate of Origin检查工具贡献者必须在提交信息中添加Signed-off-by行以确认遵守相应要求。Git 提供了-s参数自动追加git commit -s -m This is my commit message完整提交流程git add -A git commit -s #-a git push --force-with-lease $user my_feature提交信息应遵循 How to Write a Git Commit Message 的约定并在提交信息中引用相关 issueGFM 语法如Closes #XXX与Fixes #XXX这样 PR 合并时 issue 会自动关闭。文档还建议在仓库根目录安装 git-good-commit 钩子来辅助编写合规提交信息。PR 提交与自动化测试创建 PR分支准备好后推送到自己的 forkgit push --force-with-lease $user my_feature然后访问自己的 fork 页面点击my_feature分支旁的Compare Pull Request按钮创建 PR。PR 描述应引用其解决的所有 issue。PR 打开后会被分配给一位或多位评审者他们将围绕正确性、bug、改进空间、文档注释与代码风格进行细致评审。针对评审意见的修改请提交到 fork 上的同一分支。双层 CI 校验PR 打开后Harbor 会运行两条 CI 流水线1. Travis CI源码静态检查 单元测试通过golint、go vet、go race检查代码的可读性、安全性与正确性通过go test触发全部单元测试关注 Travis 结果与覆盖率报告若 Travis 失败需判断是否为你的提交引入若覆盖率显著下降需补充覆盖新代码的单元测试。2. Drone CIE2E 测试 gosec 安全检查从源码构建并安装 Harbor然后运行四个基础 E2E 测试验证核心功能Registry 基础验证镜像能否成功 push 与 pullTrivy 基础验证镜像能否成功扫描Notary 基础验证镜像能否成功签名LDAP 基础验证Harbor 能否在 LDAP 环境下正常工作源码会通过gosec检查结果存入 Google Storage 供后续分析。报告 Issue高质量缺陷反馈报告 issue 同样是重要的贡献方式。打开 issue 前请先检索现有 issues 避免重复提交若找到匹配项可订阅该 issue 获取更新通知并在评论中补充有帮助的信息。报告 issue 时务必包含Docker engine 与 docker-compose 的版本Harbor 的配置文件/var/log/harbor/下的日志文件。由于 issue 公开可见提交日志与配置前必须移除敏感信息用户名、密码、IP 地址、公司名称等可用REDACTED或****等字符串替换。如有可复现步骤请一并提供这能显著加速问题的定位与修复。文档贡献要求若你正在创建或修改功能请同步更新文档——好的文档与代码同样重要。文档使用 Markdown 编写文档图片可放置于docs/img目录本仓库的 docs/img 中已有 Harbor logo 等资源。新特性提案流程提交新特性或对现有代码的修改可遵循以下流程先确认是否已有人在做同时检索主仓库的 Issues 与 PRs以及 Community 仓库在community/proposals/new目录下基于现有模板提交新提案提案必须标注为kind/proposal提案可结合社区、维护者与其他贡献者的意见不断修改完善整体架构需与 Roadmap 保持一致避免重复工作提案应在社区会议上向维护者与贡献者展示讨论评审通过后可由提案提交者或任何社区成员实现——项目高度社区驱动非常鼓励后续者接手实现实现过程中及完成后PR 由维护者与贡献者按最佳实践评审新 PR 合并后提案需移入community/proposals并标记为已完成。小结贡献者的完整检查清单Fork 仓库并按 Go workspace 约定克隆到GOPATH配置goharbor与个人 fork 两个 remote在XXX-description命名的新分支上开发行宽控制在 120 字符提交前运行go list ./... | grep -v -E tests | xargs -L1 fgt golint通过 lint本地运行make go_check与go test -v ./...通过全部校验新增/修改 API 时先改api/v2.0/swagger.yaml再make gen_apis最后更新src/server/v2.0/handler用src/.mockery.yamlmake gen_mocks为新增接口生成 mock用git commit -s提交并引用相关 issueCloses #XXX/Fixes #XXX以git push --force-with-lease $user my_feature推送并创建 PR关注 Travislint/vet/race/单元测试与 DroneE2E gosec结果按评审意见迭代。遵循上述流程你的贡献将进入 Harbor 的持续演进之中——这正是开源项目社区驱动模式的运转方式。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Harbor 开源贡献指南：从 Fork 到合入的完整实战流程
Harbor 开源贡献指南从 Fork 到合入的完整实战流程【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor本篇指南围绕 Harbor 云原生镜像仓库项目的社区贡献规范展开系统梳理了从环境搭建、代码获取、分支管理、开发测试到提交 PR 的完整流程并结合仓库内 Makefile、src/.mockery.yaml 等源码级证据帮助读者理解 Harbor 的代码库结构、Make 驱动开发工作流、controller/manager/dao编程模型与双层 CI 校验机制。读完本文你将掌握向 Harbor 提交高质量代码与提案的完整方法也能对照源码快速定位各功能模块的所在位置。Harbor 社区协作生态概览Harbor 以开放方式开发由用户、贡献者与维护者共同持续改进。作为 CNCF 托管的云原生镜像仓库它的贡献者除了使用 GitHub issue tracker 外还可以通过以下渠道协作双周公开社区会议以及过往会议的录像回放CNCF Slack 上的#harbor终端用户讨论与#harbor-dev开发讨论频道harbor-users与harbor-dev两个邮件列表分别用于用户交流与开发讨论。起步Fork 与本地环境准备Fork 仓库在 GitHub 上将 Harbor 仓库 Fork 到个人账户后按 Go 的 workspace 约定把代码放到GOPATH下。文档给出的标准流程如下# 设置 golang 环境 export GOPATH$HOME/go mkdir -p $GOPATH/src/github.com/goharbor # 获取代码 cd $GOPATH/src/github.com/goharbor/harbor git clone gitgithub.com:goharbor/harbor.git # 将远端重命名为 goharbor并添加自己的 fork git config push.default nothing # 避免默认推送到 goharbor/harbor git remote rename origin goharbor git remote add $USER gitgithub.com:$USER/harbor.git git fetch $USER其中GOPATH可以是任意目录示例使用$HOME/go$USER需替换为你的 GitHub 用户名。git config push.default nothing是一道安全措施防止误把本地提交推到上游。构建项目构建与编译流程可参考 Harbor 官方编译指南从仓库内的 Makefile 可以看到make install实际串联了compile build prepare start四个阶段而make顶层目标依次完成环境准备、编译二进制、构建镜像与安装镜像。仓库结构快速定位代码Harbor 顶层目录的组织方式如下. ├── contrib # 社区贡献的文档、脚本等辅助内容 ├── make # 构建与搭建 Harbor 环境所需的资源 ├── src # 源码目录主要工作目录 ├── tests # API 测试与 e2e 测试用例 └── tools # 支撑工具src是你日常开发的主战场其关键子目录对应关系为目录职责src/cmd含 DB 升级迁移脚本等入口如 standalone-db-migratorsrc/common通用组件如 dao、models、rbac、secret、security 等src/controllerAPI handler 使用的控制器层覆盖 artifact、project、scan、replication 等业务src/core核心业务逻辑含 REST API 与各类服务src/jobservice任务服务组件job、logger、period、worker 等src/portalHarbor Web UI 代码src/registryctl处理 registry 管理逻辑的控制器src/serverAPI 层含 v2.0 handler 等src/testing测试相关工具与 mock 生成物从src/go.mod可以看到模块名为github.com/goharbor/harbor/srcGo 版本要求为 1.26.4与实际构建时使用的GOBUILDIMAGEgolang:1.26.4见 Makefile一致。开发环境搭建Go 与 Web 双栈Go 后端环境Harbor 后端使用 Go 编写不同版本对 Go 版本有明确要求。文档给出从 1.1 到 2.16 的完整对应表这里摘录近期关键版本Harbor要求 Go2.101.21.82.111.22.32.121.23.22.131.23.82.141.24.62.151.26.42.161.26.4当前仓库版本src/portal/package.json 标注 2.15.0对应 Go 1.26.4。搭建环境时需确保GOPATH与PATH按 Go 环境说明正确配置。Web 前端环境Harbor Web UI 基于 Clarity 与 Angular 框架构建需要先安装 npm。仓库当前实际使用的 Angular 为 21.x见 src/portal/package.json。文档给出的历史版本对应关系节选如下Harbor要求 Angular要求 Clarity1.87.1.31.0.01.97.1.31.0.02.08.2.02.3.82.18.2.02.3.82.210.1.24.0.22.310.1.24.0.22.412.0.35.3.0贡献工作流分支、开发与同步PR 始终欢迎即使只是修正拼写或几行代码的小改动。但若有较大改动建议先开 issue 展开讨论再动手实现同时提倡以小步快跑的方式拆分 PR——一个包含大量特性与改动的巨型 PR 很难评审。注意拆分后的每个小改动合入main时都不能破坏现有功能否则该 PR 在该特性完成前无法合并。分支规范改动应在自己 fork 的新分支上进行分支命名为XXX-descriptionXXX为 issue 编号。PR 应基于mainrebase且不要混入多个分支的内容。当 PR 无法干净合并时按以下步骤保持同步# goharbor 是上游 origin cd $working_dir/harbor git fetch goharbor git checkout main git rebase goharbor/main从更新后的main切出新分支git checkout -b my_feature main开发与同步上游编码风格遵循 Golang 社区建议代码与 Markdown 文档的行宽尽量控制在 120 字符以内。项目强制 golint 标准提交前应在源码上运行 golint若报出问题优先按 lint 建议修正代码golint 依据 Effective Go 与 CodeReviewComments 给出建议# 安装 fgt 和 golint go install golang.org/x/lint/golintlatest go install github.com/GeertJohan/fgtlatest # 在 $working_dir/harbor 下执行 go list ./... | grep -v -E tests | xargs -L1 fgt golint分支与goharbor/main失步时使用fetch / rebase而非git pullgit pull会产生合并提交污染提交历史违背每个提交应当独立可理解、有用的原则。也可通过git config branch.autoSetupRebase always改变git pull的行为。推荐的 Make 命令工作流Harbor 提供了一套 Makefile 驱动的开发工作流。对照 Makefile 源码常用命令及其底层行为如下测试与校验make go_check # 运行测试、API 生成、lint、vet、race、拼写检查从 Makefile 可见go_check实际串联了gen_apis mocks_check misspell commentfmt lint其中gen_apis用 go-swagger 从 api/v2.0/swagger.yaml 生成 API servermocks_check通过 src/.mockery.yaml 重新生成 mock 后比对 git status确保 mock 未过期misspell检查 Go 文件拼写错误commentfmt检查//与注释正文之间是否缺少空格lint在src/下执行 golangci-lint超时 10 分钟。构建指定服务make compile_core # 构建 core 服务二进制 make compile_jobservice # 构建 jobservice 二进制后台任务 make compile_registryctl # 构建 registryctl 二进制registry 管理从 Makefile 看这三个目标都是在golang:1.26.4容器内交叉编译产物分别输出到make/photon/core/harbor_core、make/photon/jobservice/harbor_jobservice、make/photon/registryctl/harbor_registryctl。此外还有compile_standalone_db_migrator产物migrate与compile一次性串联 core、jobservice、registryctl 三个编译目标。TLS 证书生成与清理make gen_tls # 仅生成 TLS 证书 make cleanall # 移除所有二进制、镜像与生成的配置 make cleanbinary # 仅移除编译产物 make cleanimage # 仅移除构建的 Docker 镜像 make cleanconfig # 仅移除生成的配置文件cleanall由cleanbinary cleanimage cleanbaseimage cleandockercomposefile cleanconfig cleanpackage聚合而成见 Makefile。构建环境中还可用make check_environment调用 make/checkenv.sh 一键校验 golang、docker、docker-compose 是否就绪。测试后端与前端双框架提交 PR 前应确保改动经过充分测试。Harbor 对后端与前端使用不同的测试框架后端Go服务使用 Go 内置的go testing框架Web UIAngular/Clarity使用 Jasmine 与 Karma。运行单元测试新增代码应配套单元测试。Go 测试命令# cd $working_dir/src/[package] go test -v ./...UI 库测试命令# cd $working_dir/src/portal/lib npm run test从 src/portal/package.json 可见前端测试实际执行ng test --code-coverage另有test:headless无头 Chrome、test:watch等变体可用于不同场景。后端编程模型与 mock 生成Harbor 现在采用controller/manager/dao编程模型建议使用 testify mock 测试controller与manager。项目集成了 mockery 基于 testify mock 包为 Go 接口生成 mock先在src/.mockery.yaml中添加 mock 配置然后运行make gen_mocks生成 mock。查看 src/.mockery.yaml 可以看到配置覆盖了 controller 层artifact、project、scan、replication、robot、retention 等、jobservice 层mgt、period、common/lib 层cache、orm、config与 pkg 层task、user、oidc、rbac 等的数百个接口mock 默认输出到testing/对应目录例如testing/controller/artifact、testing/pkg/scan。提交前make go_check中的mocks_check会校验这些生成的 mock 文件是否与最新接口保持一致。新增或修改 API 的正确姿势从 v2.0 起Harbor 使用 go-swagger 从 Swagger 2.0OpenAPI 2.0规范生成 API server。若要新增或修改 API流程是先更新api/v2.0/swagger.yaml文件运行make gen_apis生成 API server 代码最后在src/server/v2.0/handler包中实现或更新对应的 API handler。从 Makefile 的gen_apis目标可见它会基于api/v2.0/swagger.yaml重新生成src/server/v2.0下的models与restapi再执行 go-swagger 的generate server。当前 src/server/v2.0/handler 下已存在 80 余个 handler 文件覆盖 artifact、auditlog、config、gc、immutable、ldap、member、oidc、project、purge、quota、registry、replication、repository、retention、robot、scan、scanner、schedule、search、security、systeminfo、user、usergroup、webhook 等全部核心 API。提交与 DCO 签名Harbor 集成了 DCODeveloper Certificate of Origin检查工具贡献者必须在提交信息中添加Signed-off-by行以确认遵守相应要求。Git 提供了-s参数自动追加git commit -s -m This is my commit message完整提交流程git add -A git commit -s #-a git push --force-with-lease $user my_feature提交信息应遵循 How to Write a Git Commit Message 的约定并在提交信息中引用相关 issueGFM 语法如Closes #XXX与Fixes #XXX这样 PR 合并时 issue 会自动关闭。文档还建议在仓库根目录安装 git-good-commit 钩子来辅助编写合规提交信息。PR 提交与自动化测试创建 PR分支准备好后推送到自己的 forkgit push --force-with-lease $user my_feature然后访问自己的 fork 页面点击my_feature分支旁的Compare Pull Request按钮创建 PR。PR 描述应引用其解决的所有 issue。PR 打开后会被分配给一位或多位评审者他们将围绕正确性、bug、改进空间、文档注释与代码风格进行细致评审。针对评审意见的修改请提交到 fork 上的同一分支。双层 CI 校验PR 打开后Harbor 会运行两条 CI 流水线1. Travis CI源码静态检查 单元测试通过golint、go vet、go race检查代码的可读性、安全性与正确性通过go test触发全部单元测试关注 Travis 结果与覆盖率报告若 Travis 失败需判断是否为你的提交引入若覆盖率显著下降需补充覆盖新代码的单元测试。2. Drone CIE2E 测试 gosec 安全检查从源码构建并安装 Harbor然后运行四个基础 E2E 测试验证核心功能Registry 基础验证镜像能否成功 push 与 pullTrivy 基础验证镜像能否成功扫描Notary 基础验证镜像能否成功签名LDAP 基础验证Harbor 能否在 LDAP 环境下正常工作源码会通过gosec检查结果存入 Google Storage 供后续分析。报告 Issue高质量缺陷反馈报告 issue 同样是重要的贡献方式。打开 issue 前请先检索现有 issues 避免重复提交若找到匹配项可订阅该 issue 获取更新通知并在评论中补充有帮助的信息。报告 issue 时务必包含Docker engine 与 docker-compose 的版本Harbor 的配置文件/var/log/harbor/下的日志文件。由于 issue 公开可见提交日志与配置前必须移除敏感信息用户名、密码、IP 地址、公司名称等可用REDACTED或****等字符串替换。如有可复现步骤请一并提供这能显著加速问题的定位与修复。文档贡献要求若你正在创建或修改功能请同步更新文档——好的文档与代码同样重要。文档使用 Markdown 编写文档图片可放置于docs/img目录本仓库的 docs/img 中已有 Harbor logo 等资源。新特性提案流程提交新特性或对现有代码的修改可遵循以下流程先确认是否已有人在做同时检索主仓库的 Issues 与 PRs以及 Community 仓库在community/proposals/new目录下基于现有模板提交新提案提案必须标注为kind/proposal提案可结合社区、维护者与其他贡献者的意见不断修改完善整体架构需与 Roadmap 保持一致避免重复工作提案应在社区会议上向维护者与贡献者展示讨论评审通过后可由提案提交者或任何社区成员实现——项目高度社区驱动非常鼓励后续者接手实现实现过程中及完成后PR 由维护者与贡献者按最佳实践评审新 PR 合并后提案需移入community/proposals并标记为已完成。小结贡献者的完整检查清单Fork 仓库并按 Go workspace 约定克隆到GOPATH配置goharbor与个人 fork 两个 remote在XXX-description命名的新分支上开发行宽控制在 120 字符提交前运行go list ./... | grep -v -E tests | xargs -L1 fgt golint通过 lint本地运行make go_check与go test -v ./...通过全部校验新增/修改 API 时先改api/v2.0/swagger.yaml再make gen_apis最后更新src/server/v2.0/handler用src/.mockery.yamlmake gen_mocks为新增接口生成 mock用git commit -s提交并引用相关 issueCloses #XXX/Fixes #XXX以git push --force-with-lease $user my_feature推送并创建 PR关注 Travislint/vet/race/单元测试与 DroneE2E gosec结果按评审意见迭代。遵循上述流程你的贡献将进入 Harbor 的持续演进之中——这正是开源项目社区驱动模式的运转方式。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考