11个版本
0.1.1 | 2022年4月21日 |
---|---|
0.1.0 | 2022年1月24日 |
在开发工具分类中排名第1327
每月下载量28次
355KB
2.5K SLoC
Tribble
TL;DR Tribble是一个命令行工具,可以从单个配置文件生成微型网站,以指导用户为开源项目做出贡献。
问题
想象一下,你是一个新手用户,你想在项目的文档中添加一个页面。 但是,他们使用的是一个定制的文档系统,而这个系统讽刺性地没有文档。 CONTRIBUTING.md
文件只说克隆仓库并使用提供的构建脚本,但这些脚本也没有文档!通常,大多数用户现在就会放弃。有些人可能会在仓库中打开一个问题或在一些其他渠道中提问,然后他们可能会在这个过程中得到指导。但这并不能帮助下一个用户或他们之后的用户。如果你继续在 CONTRIBUTING.md
文件中添加内容,它往往会变成一系列关于怪癖的随机事实的集合,而不是一个有用的资源。这就是Tribble的用武之地。
作为维护者,我们希望专注于编写代码,而不是编写文档,更不用说编写关于如何编写文档的文档了!在大型仓库中,人们可以以无数种方式做出贡献,但传统的 CONTRIBUTING.md
文件无法涵盖它们所有,而且如果你项目足够大,你可能会花费更多的时间帮助人们了解如何贡献,而不是真正解决问题。
作为用户,为大型项目做出贡献可能会让人感到害怕,我们想确保我们做的是正确的事情。但是,如果文档不完整,或者更糟,根本不存在,那会非常困难!对于大型项目,很多高质量的贡献者可能会在早期阶段就失去了如何贡献的思路。
解决方案
如果每个项目都有一个涵盖所有贡献方式的巨型流程图,并包含每个部分的特有信息,那会怎么样?如果维护者可以写一个包含所有必要信息的配置文件来指导人们如何贡献到他们的项目,那会怎么样?如果这个流程图是交互式的,有按钮和文本输入来引导用户完成贡献过程,又会怎么样?如果这也适用于问题,新手被引导提供所有必要的报告bug的信息,又会怎么样?如果这个过程能够为问题自动生成标签,从而有效地提供自动问题分类呢?
这就是 Tribble。
Tribble 是一个命令行工具,它读取 YAML 编写的配置文件,并将其转换为使用 Perseus 制作的全功能网站,该网站包含一个交互式流程图,用于指导用户完成贡献过程。在每一个阶段,都可以累积 标签,这些标签可以自动添加到通过 Tribble 报告的 GitHub 问题中。它旨在简化编写和维护贡献文档的过程,指导用户提供维护者分类问题所需的信息,并自动执行基本分类(分配用户和添加标签)。
安装
Tribble 是一个完全自包含的二进制文件,使用 Rust 构建,以确保性能和安全,您可以从 发布页面 下载,或者使用 Cargo,Rust 的包管理器。
手动下载
如果您不使用 Rust,最简单的方法是从 发布页面 下载适用于您系统的最新二进制文件,然后将它放在您放置二进制文件的任何地方(例如,Linux 上的 /usr/local/bin
)。
Tribble 会自动为 Windows、MacOS、Linux 和 Linux musl(特别是为 Alpine Linux Docker 容器)生成二进制文件。如果您需要其他平台的二进制文件,您需要使用 Cargo 手动编译它,您可以通过 这里 的说明进行安装。然后按照使用 Cargo 安装 Tribble 的说明操作,您就准备就绪了!(此外,如果您认为我们应该为您的平台提供二进制文件,请随时 提交问题)。
使用 Cargo
如果您已安装 Cargo,只需运行以下命令即可:
RUSTFLAGS=--cfg=web_sys_unstable_apis cargo install tribble
关于 `RUSTFLAGS` 的那部分是什么意思?
Tribble 使用剪贴板 API 来方便用户,我们通过名为 web_sys
的 crate 在 Rust 中实现这一点,它公开了 Web API。目前,剪贴板的 API 是不稳定的,需要为 rustc
提供此标志才能正常工作。遗憾的是,这不能放入配置文件中,最终用户必须设置它。不过,请放心,您只需在运行 cargo install
时做一次,这不会更改您的系统上的任何其他设置。如果您担心,您始终可以使用 发布页面 上的二进制文件。
其他包管理器
将来,Tribble 将通过更多的包管理器分发,以使安装更加方便。
用法
Tribble CLI接受一个配置文件,它期望这个文件位于项目的根目录中,文件名为tribble.yml
。如果您需要命名其他名称,请随意命名,并通过传递-c <您的-配置-文件-名称-在这里>
来通知CLI。无论您如何命名,它都必须以YAML格式编写。为了开始,请在目录中将以下内容放入tribble.yml
。
workflows:
test:
sections:
Start:
- "Hello, and welcome to the first stage of your contribution journey with Tribble!"
- { text: "I want to report a bug", link: "Report Bug", tags: [ "C:bug" ] }
- { text: "I want to suggest an enhancement", link: "Request Enhancement", tags: [ "C:enhancement" ] }
- { text: "I'd like to add something to the docs", link: "endpoint:Documentation", tags: [ "C:docs" ] }
Report Bug:
- "Welcome to the section for reporting bugs!"
- { id: "bug_description", label: "Describe the bug", type: "text" }
- { id: "test_textarea", label: "Textarea", type: "multiline" }
- { id: "test_datetime", label: "Datetime", type: "datetime-local" }
- { id: "bool", label: "Boolean", type: "boolean" }
- { text: "This bug occurs on the frontend", link: "endpoint:Bug", tags: [ "A:frontend" ] }
Request Enhancement:
- "Welcome to the section for suggesting enhancements!"
- { id: "feature_area", label: "Which area of the system does your feature affect?", options: [ "Frontend", { text: "Backend", tags: [ "A:backend" ] } ], can_select_multiple: true }
- { id: "test_select", label: "Which of the following best describes you?", options: [ "User", "Developer" ] }
- { text: "Continue", link: "endpoint:Enhancement", tags: [] }
index: Start
endpoints:
Bug:
preamble: "Thank you very much for reporting this bug, we'll get on it right away!"
text: "This report is reporting a bug. Description: ${bug_description}. Boolean: ${bool}"
dest_text: "Report on GitHub"
dest_url: "#"
Enhancement:
preamble: "Thanks for the request, we'll take a look!"
text: "This report is requesting an enhancement to the ${feature_area}."
dest_text: "Report on GitHub"
dest_url: "#"
Documentation: "You can contribute to the docs by doing foobar!"
这是如何工作的?
这是Tribble配置文件的结构,它有一个顶级属性workflows
。在这个例子中,我们定义了一个名为test
的工作流程(在生成的网站上将可在/workflows/test
处访问),并包含几个部分。我们将名为Start的部分标记为index
,因此工作流程将从这里开始。然后,我们定义一个简单的段落以供显示,然后定义两个按钮,根据用户的输入导航到不同的部分。请注意,根据用户按下哪个按钮,他们将积累不同的标签(例如,选择Report Bug将添加C:bug
标签)。在Report Bug部分中,我们定义了一些输入,包括一个用于简短错误描述的text
输入(在现实生活中你可能使用multline
),一个multiline
,一个datetime-local
和一个boolean
。然后,我们创建另一个按钮,其链接的起始位置有endpoint:
,这意味着它将被发送到一个端点,特别是Bug端点。如果我们查看endpoints:
下的内容,我们会看到它有一个序言段落和一些文本,用户可以将这些文本复制到类似GitHub issue的地方。然后,我们定义了一个按钮的属性,将用户带到可以报告问题的位置。请注意,这里的text
字段使用了${...}
插值语法,允许它引用工作流程中任何输入的值。在这里,我们插入了用户提供的错误描述。如果输入未标记为optional: true
,您可以确信它将在这里存在。唯一值得注意的其他事情是Documentation端点,它不是像Bug那样的报告端点,而只是提供说明。这些说明端点对于引导用户创建不同类型的pull请求到您的项目特别有用。
文件准备好后,现在在同一个目录下运行tribble serve
,这将立即(根据我们的测试,大约37毫秒)为您生成一个应用程序的网站,您可以在https://127.0.0.1:8080上查看。如果您想更改主机或端口,可以使用适当的--host
和--port
标志来运行命令。
这就是Tribble的工作方式!您可以在这里查看完整的API文档(自动从Rust代码生成)。
国际化
我们刚刚所做的一切都很好,但大型项目通常需要多种语言的文档,那么Tribble是如何处理这个问题的呢?好吧,如果您在tribble.yml
中创建一个包含此内容的Tribble文件,您就会看到!
languages:
en-US: en-US.yml
这定义了我们将支持的语言以及它们对应的配置文件链接。然后,在en-US.yml
中,将有一个名为 test
的工作流可用,位于 /workflow/en-US/test
。您可以随意命名本地化版本,但我们推荐使用 [language]-[REGION]
的方法(例如:en-US、
en-GB、
zh-CN、
ru-RU
)。有了这个,您的 Tribble 实例现在可以支持您想要支持的所有语言!
CLI 命令
Tribble CLI 支持仅五个命令,但它们可以用于为贡献者创建复杂且直观的用户体验。请注意,您可以通过顶级标志 -c
/--config
更改配置文件的存储位置(例如:tribble -c test.yml serve
)。
build
-- 构建您的流程(由tribble serve
自动调用,因此除非您想调查底层文件,否则通常不需要此命令)clean
-- 在数据损坏时清除 Tribble 元数据deploy
-- 将您的流程构建为静态文件以进行部署,生成pkg/
文件夹(可使用-o
/--output
进行更改)help
-- 显示 CLI 的帮助页面,该页面将告诉您本节的所有内容serve
-- 在本地开发时提供您的流程,监视 Tribble 配置文件的变化(如果您添加了新的本地化版本,则需要重新运行)
部署
构建了一些 Tribble 工作流并将其部署到您的网站后,运行 tribble deploy --path <serve-path>
(其中 <serve-path>
是您将提供 Tribble 的相对路径的 URL,例如 /tribble
)以生成 pkg/
文件夹。该文件夹将包含您可以部署到任何支持提供静态资产的托管提供商的静态文件。例如,在 GitHub Pages 上,您只需将此文件夹添加到网站的根目录,并将其重命名为 tribble
,然后您就可以在 https://<your-username>.github.io/<your-repo>/tribble/workflow/test
访问 test
工作流。生成的文件完全适合生产使用,并且它们将使用 Perseus 构建一个性能极好的网站,该网站在浏览器中使用 Rust 实现最大性能。请注意,但您的流程只能在支持 WebAssembly 的浏览器中使用(基本上除了 Internet Explorer 以外的所有浏览器)。通常,可能为开源项目做出贡献的开发商将拥有现代浏览器。
如果您想在同一个地方托管多个项目的 Tribble 实例,不要担心,这正是工作流的目的!您可以定义尽可能多的工作流(只要它们在所有本地化版本中相同),然后可以使用一个 Tribble 实例为许多完全不同的项目(或仅为非常大的项目的一部分)服务。
如果您访问已部署的 Tribble 实例,发现网站未加样式(即整个屏幕充满大量箭头),请确保在 tribble deploy
中 --path
设置正确。Tribble 使用此设置来确定其位置,以及其 CSS 文件的位置,因此当此设置不正确时,它看起来未加样式。
与 GitHub 集成
Tribble 最强大的功能之一是允许用户在通过工作流程的过程中累积标签。更好的是,这些标签可以通过 Tribble bot 自动转换为 GitHub 上的标签!这个功能的主要好处是问题可以完全自动分类,从而更快地响应问题并更容易进行项目管理。
目前,Tribble 仅支持与 GitHub 集成,但我们非常愿意考虑开发其他平台集成的可能性,如果感兴趣的话!
许可
请参阅 LICENSE
。
依赖项
~23–36MB
~558K SLoC