cssmagic / kup Goto Github PK

位置

$HOME/.cmcm/kup/config.json

结构

单用户：

{
  "tokens":{
    "github":"___access__token___"
  }
}

多用户：

{
  "tokens":{
    "github":{
      "username1":"___access__token___",
      "username2":"___access__token___"
    }
  }
}

🤔 默认用户如何指定？每次询问还是自动取第一个？

多平台：

{
  "tokens":{
    "github":{
      "username1":"___access__token___",
      "username2":"___access__token___"
    },
    "gitlab":"___access__token___"
  }
}

这是迟早要做的。

这个功能具体怎么设计，还需要好好想想。是支持多个文件，还是支持 glob，还是支持自动获取近期变更的……

本文已迁移到： cssmagic/Footprint#7

增加 -d --dump 布尔值选项，如果有，则进行反向操作（不是发布，而是采集）。

获取 repo 和 id 参数的逻辑不变。

此时如果不指定文件，则自动在当前目录生成一个文件，命名为 {repo-owner}--{repo-name}--{id}.md。采集成功后写入 YAML 元数据。

这是目前的已知问题。

但具体怎么处理，需要想一想。因为后续会支持批处理多文件，需要综合考虑。

用户可能会通过环境变量指定代理：

export https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890

需要识别这个代理配置并通过此代理发送请求。

注意事项

如果 repo 参数是猜测出来的，在进行下一步操作之前，需要向用户确认。

参考

向上查找指定文件或目录：
https://github.com/sindresorhus/find-up

背景

需要在 Markdown 文件内添加一些元数据，以便 Kup 正确投递。

考虑到在 Markdown 顶部添加 YAML 格式的元数据已是较为普遍的做法：

• Jekyll - YAML front matter
• R Markdown - YAML header
• Pandoc - YAML metadata block
• 甚至 GitHub 也可以对仓库内的 Markdown 文件进行 YAML 元数据的解析，并渲染为表格。（但 issue 不行。）
• 很多 Markdown 编辑器或浏览器也支持 YAML 格式的元数据，比如 MacDown、QLMarkdown 等。

因此，Kup 也打算采用这种方式。

示意

---
title: The title of this issue
repo: cssmagic/kup
id: 168
tags:
  - JS
  - RFC
---

Markdown 正文
Markdown 正文
Markdown 正文

功能点

• 解析 Markdown 文件中的 YAML 元数据和 H1 标记。
• 通过命令行获取 repo 和 id 等参数。
• 通过指定的 repo 和 issue 参数，把 Markdown 更新到现有 issue。
• 通过指定的 repo 参数，把 Markdown 发布为新 issue。
• 发布新 issue 之前向用户确认。
• 当未找到 GitHub Token 时提醒用户。

API

kup <file> [--repo aaa/bbb] [--id 123]

准备工作：需要测试一下，最小化的权限范围是哪些。

目前是拿 RFC #1 凑数，回头还是要写一篇正式的文档。

允许用户在 package.json 中一次性指定目标 repo。

背景

操作 GitHub issue 是需要权限认证的，因此你需要向 Kup 提供 GitHub token，以便 Kup 调用 GitHub API。

步骤

1. 进入 “Personal access tokens” 页面可以查看已经生成的 token。点击右上角的 “Generate new token” 按钮开始生成一个新的 token。

   

2. 在生成新 token 之前，GitHub 通常会要求你输入登录密码来验证身份。毕竟是涉及身份和权限的敏感操作，安全第一。

   

3. 验证通过，进入生成 token 的表单，填写必要的信息：

   • 在 “Note” 一栏输入用途（比如给 Kup 用的就填 “Kup”）。
   • 在 “Expiration” 一栏选择 token 的有效期。出于安全考虑，GitHub 不建议选择无限期。
   • 在 “Select scopes” 这里勾择 token 的权限范围：
     • 如果只需要在公开仓库发布或更新 issue，可以只选择 “public_repo”。
     • 如果需要在私有仓库发布或更新 issue，需要选择 “repo”。

   

   点击页面底部的 “Generate token” 按钮即可生成新 token。

4. 随后我们回到第 1 步的 token 列表页，可以看到新 token 的明文，我们需要立即把它复制下来并妥善保管。因为刷新页面之后，GitHub 将不再展示 token 内容。如果遗忘了这个 token，我们只能把它删除后重新生成。

   

注意事项

• 拥有 token 的人可以在不知道你的密码的情况下以你的名义调用 GitHub API，它在一定程度上就相当于你的账号密码，因此不要把 token 告诉其他人。

• 如果你把 token 写入代码并提交到 GitHub 上的公开仓库，或者把它发布到公开仓库的 issue 或评论内，相当于这个 token 已经泄漏，那么 GitHub 出于安全考虑会立即删掉这个 token。

提示

由于 Kup 目前还没有保存 token 的功能，你需要在使用 Kup 之前通过环境变量把 token 传递给 Kup：

export GITHUB_TOKEN=ghp_**********

为了避免每次使用 Kup 之前都要重复这个动作，你可以把这行命令写入 ~/.zshrc 或 ~/.bash_profile 这样的终端初始化文件。

注意事项

如果 repo 参数是猜测出来的，在进行下一步操作之前，需要向用户确认。

参考

定位 Git 仓库的根目录：

git rev-parse --show-toplevel

获取 origin 的地址：

git remote get-url origin

Node.js 调用 Git 命令：
https://github.com/typicode/husky/blob/main/src/index.ts#L9-L10

• 整合到 IDE（WebStorm 等）
• 整合到 Git hook。