bgo v0.3.0+
前言
我们已经在 bgo: 让构建 go 程序更容易 中介绍了 bgo 的基本能力。
经过几天的迭代,初步感觉到比较稳定了,因此发了 0.3.0 版本,作为是春节前的划断。
新版本有了
节后嘛,得益于 cmdr 原有的 Aliases 功能的升级(除夕时遇到很多意外,都是忙乱惹的祸),bgo 向着不仅只是个 main 包批量构建器
迈出了一小步:
我们通过 Aliases 的方式提供了预建的 check-code-quanlities 功能。
这是 v0.3.1+ 之后提供的新功能。
check-code-qualities 功能
这个功能是需要第三方工具的。当前需要 golint 和 gocyclo 在场,此外也需要 gofmt 工具。前两者需要提前安装:
go install golang.org/x/lint/golint
go install github.com/fzipp/gocyclo
当上述工具有效时,bgo 可以代为行使上述工具提供的质量检查功能:
bgo check-code-quanlities
bgo chk
# Or
bgo chk ./...
这个命令依次执行 gofmt, golint 以及 gocyclo 工具,对你的当前文件夹以及下级进行代码质量检测。
你可以附带参数如 ./...
或者其它指定的文件夹偏移。
Homebrew
brew 版本预建了安装脚本,你需要更新 hedzr/brew Tap 然后 reinstall bgo。
由于 brew 通过 update 命令来更新它自己以及所有的taps,因此其效率可能太低下。我觉得,一个变通的方法是:
brew untap hedzr/brew
brew tap hedzr/brew
brew 现在会安装预置配置文件到 /usr/local/etc/bgo/。
后文我们会介绍其它环境应该怎么办。
正文
上面提到的功能,是依赖于 cmdr 的 Aliases 能力。因此我们对此有必要进行解释。
bgo 新版本的安装
首先来讲,现在 bgo 的 release 下载包中携带了一个 etc/bgo 子目录,你需要将其移动为 $HOME/.bgo
目录:
wget https://github.com/hedzr/bgo/releases/download/v0.3.3/bgo-darwin-amd64.tgz
tar -xf bgo-darwin-amd64.tgz
mv bin/bgo /usr/local/bin/bgo
mv etc/bgo ~/.bgo
# 如果使用 zsh 环境,重新生成自动完成脚本
bgo gen sh --zsh
现在在 $HOME/.bgo
目录包含了预建 aliases 命令的定义。
具体来讲,它( $HOME/.bgo/conf.d/80.aliases.yml
)是这样的:
app:
aliases:
# group: # group-name (optional). such as: "别名".
commands:
# - title: list
# short-name: ls
# # aliases: []
# # name: ""
# invoke-sh: ls -la -G # for macOS, -G = --color; for linux: -G = --no-group
# # invoke: "another cmdr command"
# # invoke-proc: "..." # same with invoke-sh
# desc: list the current directory
- title: check-code-qualities
short-name: chk
# aliases: [check]
# name: ""
# group: ""
# hidden: false
invoke-sh: |
echo "Command hit: { {.Cmd.GetDottedNamePath}}"
echo "fmt { {.ArgsString}}"
gofmt -l -s -w { {range .Args}}{ {.}}{ {end}}
echo "lint { {.ArgsString}}"
golint { {.ArgsString}}
echo "cyclo ."
gocyclo -top 20 .
# invoke: "another cmdr command"
# invoke-proc: "..." # same with invoke-sh
shell: /usr/bin/env bash # optional, default is /bin/bash
desc: pre-options before releasing. typically fmt,lint,cyclo,...
想必我无需额外解释了。
这里提供了一套扩充机制(通过 shell 脚本片段),你可以继续扩充你自己的特定命令,透过 bgo 的命令系统来进一步简化构建前后的各种任务。
在上面的 yaml 代码中,解除 title: list
所在的 map 的注释即可使能一条 list 命令,这是 ls 的同义词。它当然没有实际意义,其目的在于向你解释怎么添加自己的另一条命令(或者另 n 条)。
建立多级子命令系统
在 cmdr 的 ) 的附带的配置文件 91.cmd-aliases.yml 中,为你展示了如何通过 Aliases 能力构建自己的子命令系统:
app:
aliases:
group: # group-name (optional). such as: "别名".
commands:
- title: list
short-name: ls
# aliases: []
# name: ""
invoke-sh: ls -la -G # for macOS, -G = --color; for linux: -G = --no-group
# invoke: "another cmdr command"
# invoke-proc: "..." # same with invoke-sh
desc: list the current directory
- title: pwd
invoke-sh: pwd
desc: print the current directory
- title: services
desc: "the service commands and options"
subcmds:
- title: ls
invoke: /server/list # invoke a command from the command tree in this app
invoke-proc: # invoke the external commands (via: executable)
invoke-sh: # invoke the external commands (via: shell)
shell: /bin/bash # or /usr/bin/env bash|zsh|...
desc: list the services
- title: start
flags: []
desc: start a service
- title: stop
flags: []
desc: stop a service
- title: git-version
invoke-proc: git describe --tags --abbrev=0
desc: print the git version
group: Proc
- title: git-revision
invoke-proc: git rev-parse --short HEAD
desc: print the git revision
group: Proc
- title: kx1
invoke: /kb
desc: invoke /kb command
group: Internal
- title: kx2
invoke: ../.././//kb --size 32mb # allow related path to seek a cmdr-command, and the ugly path is allowed (multiple slashes, ...)
desc: invoke /kb command
group: Internal
- title: kx3
invoke: /kb --size 2kb
desc: invoke /kb command
group: Internal
flags:
- title: name
default: noname
type: string # bool, string, duration, int, uint, ...
group:
toggle-group:
desc: specify the name of a service
不仅如此,甚至于你还能为子命令提供专属的 flag 选项。
使用标志(Flag)选项
由于 invoke, invoke-proc, invoke-sh 字段都支持模板展开,所以你可以通过模板语法提取到某个 flag 的实际值,实际值是指用户在命令行输入的,又或是该 flag 的默认值。
一个示例的 aliases 定义可以是这样:
- title: echo
invoke-sh: |
# pwd
echo "{ {$flg := index .Cmd.Flags 0}}{ {$dpath :=$flg.GetDottedNamePath}} { {$fullpath := .Store.Wrap $dpath}} { {$fullpath}} | { {.Store.GetString $fullpath}}"
desc: print the name
flags:
- title: name
default: # default value
type: string # bool, string, duration, int, uint, ...
group:
toggle-group:
desc: specify the name to be printed
该模板字符串序列几乎等价于 Golang 代码:
flg := obj.Cmd.Flags[0]
dpath := flg.GetDottedNamePath()
fullpath := obj.Store.Wrap(dpath)
stringVal := obj.Store.GetString(dpath) // 从 cmdr Option Store 中抽出该选项的实际值,以字符串的形式
模板从上下文变量环境 obj 中得到命中的子命令 echo
,即 obj.Cmd
;类似的,obj.Store
获得 cmdr Option Store 的实例,然后是一系列 cmdr 接口调用,从而获得 cmdr 处理命令行参数后设置到 Option Store 中的 --name
的实际值。
其运行的效果类似于:
$ bgo echo --name watching
app.echo.name | watching
其中,echo
子命令的完整的路径为 app.echo
,app
是隐含的前缀,cmdr 使用这样的隐含的前缀来构筑一个名字空间,而 Store.Wrap()
正是为了给一般路径附上这样的前缀。
更新你的自动完成脚本
在扩充了你的 aliases 之后,你需要更新自动完成脚本来反应变化。是的,Aliases 们是完全融入 bgo 命令系统中的,因此重新生成一次自动完成脚本,即可将 aliases 们纳入到自动完成的提示列表中。
一个示意图如上。
小节
有了上面介绍的这些信息,你将可以在不必修改 bgo 源代码的情况下,自行扩充 bgo 了。
你可以尝试:
- 添加 cov(coverage)命令,简短快捷地做覆盖测试
- bench
- 增加前置脚本以便做资源文件打包
- 等等
bgo
希望做的是将不断重复的冗长的命令行缩短到一个或者两个子命令的程度,让每次工作在 6-8 击键之内。这比你充分利用 zsh 的自动完成以及上下翻页等功能还要有用得多。
具备 Aliases 融合能力后,现在说一句 bgo: 富于扩展性的 go 程序构建工具
大约勉强也能算作是名副其实了。
关于 bgo 的配置文件
支持多种格式
同样是源自 cmdr 提供的支持,bgo 能够自动识别 json,toml 和 yml(或 yaml)后缀。
也就是说,在 一个工作目录中,存在 .bgo.yml 或者 .bgo.toml 都是可以的。尽管我们的示例中总是使用 yaml 向你讲解如何编写,但将其改变为不同的文件格式能够一样地生效。而 bgo 或者说 cmdr 则会自动加载它们。
配置文件夹
你已经注意到,我们在 $HOME/.bgo
下提供了 bgo.yml,并且其中的子目录 conf.d 中提供了 80.aliases.yml。
按照 cmdr 的约定,一个配置文件目录中一定要有同名(即 bgo
)的配置文件,至于后缀应该是 .json.toml.yml.yaml 中的一个。cmdr 的配置文件被分为三种类型:primary,secondary 以及 alternative。
对于 bgo 来说, $HOME/.bgo
是 primary 配置文件组的一个可能的位置,bgo 和 cmdr 会自动搜寻若干预定义的位置(包括 /usr/local/etc/bgo
以及 $HOME/.bgo
)来试图加载 primary 配置文件,然后将其 conf.d
作为监视文件夹,并加载其中的任何 .json.toml.yml.yaml 。
conf.d 自动配置文件夹
在主配置文件的目录里,conf.d 子目录是被监视的,这里面的任何配置文件都能够被自动重载。当然,对于 bgo 来说自动重载毫无意义。
但是你可以在这个文件夹里面添加一系列的配置文件,例如 alias-001.yml, alias-002.yml。这种结构对于 ci 操作或者说 devops 操作会是很方便的,你无需绞尽脑汁去编排脚本想一个 yaml 中添加一大段 yaml 片段,还要保证它们的嵌入位置适当,缩进层次适当。直接新增一个yml好了。
辅助配置文件
至于当前工作目录下的 .bgo.yml
,是作为 Alternative/Secondary 配置文件组的身份被载入的。
按照 cmdr 的约定,如果 .bgo.yml 被作为 Alternative 配置文件加载,则这个配置文件不含有子文件夹监视,并且可以开启自动配置文件回写功能。不过这个功能在 bgo 中并没有打开,因为回写功能会抹去配置文件中的注释部分,这可能往往并不是你所想要的。
之所以身份不定,是因此 cmdr 支持同时从 Primary/Seconary/Alternative 三个位置载入三组配置并合并到一起。尽管我们没有专门说明,bgo 在这里留有很多扩充的可能性。
在 bgo init
时改用不同格式
使用下面的语法,可以建立不同的配置文件格式:
bgo init --output=.bgo.yml
bgo init --output=.bgo.yaml
bgo init --output=.bgo.json
bgo init --output=.bgo.toml
输出文件名的后缀名决定了初始化操作将扫描结果存储为那一种配置文件格式。
后记
bgo 目前存在的问题:
- 没有 Windows 系统下的有力测试,因此不太确定配置文件的加载位置是否能被有效识别。
配置文件中的 bash shell 可能会在 windows 中改为 powershell 还是 cmd?我不太知道,或许需要少许调整才能工作。
- FEEL FREE TO ISSUE ME
上次说到,这次是突然动念,直接就做的。然后找空去看了看 goxc,哎唷我去
看了,人家干脆都停更了。
顿时觉得前途喵喵啊。
为什么我觉得 go build 交叉编译并没有那么 simple 呢,或者说麻烦的很吧。唉,不管了,反正 bgo 就是这么个工具了。
REFs
- 项目:https://github.com/hedzr/bgo
- 依赖:https://github.com/hedzr/cmdr
- 配置文件示例:https://github.com/hedzr/bgo/blob/master/.bgo.yaml
- go.dev: 这里
- Docker Hub: hedzr/bgo - Docker Image - Docker Hub
🔚