Squid Web Cache Wiki

Squid Web Cache 文档

🔗 开发者资源

🔗 贡献代码

贡献代码的最佳方式是向 GitHub 上的官方 仓库 的 master 分支提交高质量的 拉取请求。为了加快代码审查并提高代码被接受的机会，请遵守 SquidCodingGuidelines 并遵循 MergeProcedure。

《编程指南》提供了 Squid 架构的广泛概述，并详细介绍了 Squid 的一些模块。它还讨论了 如何为文档做出贡献。

自动生成的 代码文档 提供了一些关于 Squid 内部的信息，并链接到最新版本的代码。

🔗 寻找需要完成的任务

🔗 讨论代码

大多数开发讨论都发生在 开发者邮件列表 上。请只使用纯文本（不要使用 HTML 邮件）。

🔗 测试

我们使用 构建农场 进行持续集成测试。

可以使用我们用于测试不同 Linux 发行版和编译器版本代码更改的镜像。我们将这些镜像发布到 Docker Hub。它们的命名方式是 squidcache/buildfarm-<CPU 架构>-<操作系统名称>。

假设您有权访问 Docker 环境，在上面测试本地签出的最简单方法是运行以下命令：

OS=centos-7 docker run -ti --rm -v$PWD:$PWD -w$PWD -u1000 ./test-builds.sh squidcache/buildfarm-uname -m-$OS --verbose --use-config-cache --cleanup

这可能会留下一些属于 UID 1000 的文件；抱歉，无法避免。

🔗 早期发现构建错误

在提交 PR 以供审查之前发现 bug 总是更好的。由于 Squid 有大量的构建组合可能相互作用以改变构建依赖项和结果，因此在存储库中提供了一个 test-builds.sh 脚本，用于检查您的代码贡献至少能否成功编译。该脚本与将在更广泛的操作系统范围内由 CI 系统运行的脚本相同，以防止回归。

在您打算提交 PR 的 Squid 源分支的签出目录中，运行：./bootstrap.sh && ./test-builds.sh

默认的 stdout 显示仅列出构建过程中产生的 ERROR 和 FAIL 消息。并非所有这些都是问题（例如，stats 表明 0 次失败），还会提供一系列包含完整构建输出的日志。如果您对成功/失败状态有任何疑问，请查看日志末尾的总体构建结果。

提供了 --keep-going 命令行选项，以便在一次脚本执行中尽可能多地发现错误。它使用 make -k 进行构建，并尝试所有构建组合，而不是在第一次编译失败时退出。

提供了 --verbose 命令行选项，以便将完整的编译输出显示到 stdout，而不是仅显示到日志。日志仍然会生成。

其他选项适用于特定的构建情况。有关详细信息，请参阅脚本或在 squid-dev 邮件列表中询问。

🔗 重现 CI 构建农场故障

在任何安装了 Docker 的 Linux 系统上，要重现构建，您可以将 Squid 源代码签出到一个新目录，然后运行：` OS_VERSION=fedora-32 docker run -ti –rm -u jenkins -v $PWD:$PWD -w $PWD squidcache/buildfarm:uname -m-$OS_VERSION /bin/bash -l`

:warning: 将 OS_VERSION 替换为 CI 系统节点失败时的操作系统版本（例如，fedora-rawhide，debian-unstable）。

这将让您进入容器，准备进行测试。

🔗 获取源代码

有几种方法可以获取 Squid 源代码。您选择的方法决定了源代码是否经过引导，或者是否可以随着官方代码的更改而轻松更新。

🔗 通过 GitHub 获取原始源代码

官方 Squid 源代码仓库位于 GitHub。有关您可能需要执行的常用 git VCS 操作，请参阅 GitHints。

:warning: 从此仓库工作时，需要 bootstrap.sh 脚本来准备 ./configure 和相关魔法。请参阅 #Required_Build_Tools 以获取所需的引导和构建工具。

🔗 通过 HTTP 获取引导后的源代码 tarball

最新源代码可在地址 https://squid.org.cn/Versions/ 获取，其中还包含一系列前期的每日代码快照，用于测试回归和其他特殊情况。

:information_source: 显示的每日 tarball 按创建日期和 tarball 中包含的存储库修订 ID 列出。如果当天没有提交新修订，或者修订在我们创建 tarball 的机器上编译失败，列表中会出现空白。

:warning:
Daily tarballs contain the fully bootstrapped tool chain ready to
build. But be aware that some changes may appear with incomplete or
missing documentation.

作为一种更轻量级的替代方案，您可以使用 rsync 来获取最新的 tarball 内容。

🔗 通过 rsync 获取引导后的源代码

作为 tarball 的更轻量级替代方案，您可以使用 rsync；最新源代码可在地址 rsync://squid.org.cn/source/<version> 获取。

rsync 源镜像了最新发布的源代码 tarball。

:warning: rsync 源代码包含完全引导的工具链，可立即构建。但请注意，某些更改可能包含不完整或缺失的文档。

要使用此功能，您可以使用

$ rsync rsync://squid.org.cn/source
(sample output)
drwxr-xr-x         512 2011/03/20 19:14:28 .
drwxr-xr-x        1024 2009/09/17 14:13:26 squid-2.6
drwxr-xr-x        1024 2011/03/20 19:14:06 squid-2.7
drwxr-xr-x        1024 2010/07/02 13:10:53 squid-2
drwxr-xr-x        1024 2010/07/02 13:17:48 squid-3.0
drwxr-xr-x        1024 2011/03/20 19:14:21 squid-3.1
drwxr-xr-x        1024 2011/03/20 19:14:26 squid-3.2
drwxr-xr-x        1024 2011/03/20 19:14:26 squid-3.3
drwxr-xr-x        1024 2011/03/20 19:14:26 squid-3.4
drwxr-xr-x        1024 2011/03/20 19:14:26 squid-3.5
drwxr-xr-x        1024 2011/03/20 19:14:13 squid-4

选择要下载的版本后，您可以

rsync -avz rsync://squid.org.cn/source/<version> .

🔗 所需的构建工具

根据您想开发的功能，可能还需要其他库和工具。

构建用于分发的 tarball 需要以下额外工具：

从仓库代码工作时，最初需要 bootstrap.sh 脚本来运行一系列 autotools，以准备 ./configure 和相关魔法。在对 Makefile.am 或 configure.ac 脚本进行任何更改后（包括从存储库更新接收到的更改）都需要重复此操作。常见的 bootstrap.sh 问题在 ProgrammingGuide/Bootstrap 中有讨论。

🔗 杂项

发布流程 描述了 Squid 开发者在从接受的更改中创建新的 Squid 版本时使用的流程和标准。

我们是谁 解释了参与 Squid 项目的人员。

在 Squid 项目的生命周期中，已经发表了许多 论文。

导航：网站搜索，网站页面，类别，🔼 向上