bgo: an extensible go program building tool

bgo v0.3.0+

foreword

We've covered the basic capabilities of in bgo: Making it easier to build go programs161ff47ca098ca.

After a few days of iteration, I initially felt that it was relatively stable, so version 0.3.0 was released as a break before the Spring Festival.

new version has

After the festival, thanks to the upgrade of the original Aliases function of cmdr (there were many accidents on New Year's Eve, all of which were caused by a rush), bgo a step towards not only a main package batch builder Small steps:

We provide pre-built check-code-quanlities functionality via Aliases.

This is a new feature provided after v0.3.1+.

check-code-qualities function

This feature requires third-party tools. Currently the presence of golint and gocyclo is required, as well as the gofmt tool. The first two need to be installed in advance:

go install golang.org/x/lint/golint
go install github.com/fzipp/gocyclo

When the above tools are available, bgo can perform the QA functions provided by the above tools:

bgo check-code-quanlities
bgo chk
# Or
bgo chk ./...

This command executes the gofmt, golint and gocyclo tools in turn to check the code quality of your current folder and subordinates.

You can include parameters such as ./... or other specified folder offsets.

Homebrew

The brew version comes with a prebuilt install script, you need to update hedzr/brew Tap and then reinstall bgo.

Since brew updates itself and all of its taps via the update command, it might be too inefficient. I think, a workaround is:

brew untap hedzr/brew
brew tap hedzr/brew

brew will now install preconfigured profiles to /usr/local/etc/bgo/.

Later we will introduce what to do in other environments.

text

The function mentioned above is dependent on the Aliases ability of cmdr . So we need to explain this.

Installation of new version of bgo

First of all, the release download package of bgo now carries an etc/bgo subdirectory, you need to move it to the $HOME/.bgo directory:

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

The $HOME/.bgo directory now contains the definition of the prebuilt aliases command.

Specifically, it ( $HOME/.bgo/conf.d/80.aliases.yml ) looks like this:

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,...

Presumably I don't need any additional explanation.

In the official release, this file has more command alias definitions

An extension mechanism (via shell script fragments) is provided here, and you can continue to extend your own specific commands to further simplify various tasks before and after the build through bgo's command system.

In the above yaml code, uncomment the map where title: list is located to enable a list command, which is a synonym for ls. It's of course moot, its purpose is to explain to you how to add another command (or n others) of your own.

Build a multi-level subcommand system

In the configuration file 91.cmd-aliases.yml attached to cmdr's examples/fluent ), it shows you how to build your own subcommand system through the Aliases capability:

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

Not only that, but you can even provide specific flag options for subcommands.

Use the Flag option

Since the invoke, invoke-proc, and invoke-sh fields all support template expansion, you can extract the actual value of a flag through template syntax. The actual value refers to the user's input on the command line, or the default value of the flag. .

An example definition of aliases might look like this:

      - 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

This sequence of template strings is almost equivalent to Golang code:

flg := obj.Cmd.Flags[0]
dpath := flg.GetDottedNamePath()
fullpath := obj.Store.Wrap(dpath)
stringVal := obj.Store.GetString(dpath) // 从 cmdr Option Store 中抽出该选项的实际值，以字符串的形式

The template gets the hit subcommand echo from the context variable environment obj, that is, obj.Cmd ; similarly, obj.Store obtains the instance of the cmdr Option Store, and then a series of cmdr interface calls, so as to obtain the command line parameters set to the Option Store by cmdr The actual value of --name .

It works like this:

$ bgo echo --name watching
  app.echo.name | watching

Among them, the complete path of echo subcommand is app.echo , app is an implicit prefix, cmdr uses such an implicit prefix to construct a namespace, and Store.Wrap() is to attach such a prefix to the general path.

Update your autocomplete script

After extending your aliases, you need to update the autocomplete script to reflect the change. Yes, Aliases are fully integrated into the bgo command system, so regenerate the autocomplete script once to include aliases in the autocomplete prompt list.

A schematic is above.

subsection

Armed with the information described above, you will be able to extend bgo without modifying the bgo source code.

You can try:

• Add the cov (coverage) command to make coverage tests short and fast
• bench
• Add pre-script for resource file packaging
• etc

In the new version, the coverage command definition is already included in the distribution package, let's compare it.

Or directly browse the configuration file definitions in the repo ci/etc/bgo/conf.d/80.aliases.yml

bgo wants to do is reduce the lengthy repetitive command line to the level of one or two subcommands, allowing each job to be within 6-8 keystrokes. This is much more useful than you can take advantage of zsh's autocomplete and page up and down features.

With the Aliases fusion ability, let's say bgo: The extensible go program construction tool can barely be regarded as a veritable name.

In fact, we haven't introduced the Extensions feature supported by cmdr, which allows you to store a series of folders and script files in a specific folder and integrate it into the existing command system, as the Aliases feature above is configured with YAML file does.

Cmdr provides Extensions, Aliases, and Addons and other external extensions, one of the main inspiration comes from git aliases, as well as the characteristics of some DOS applications before the Internet.

Reproducing the effect in my memory in person is definitely the best reward for a developer. It doesn't matter if it is raised in a boudoir, I have already received the praise I want.

Digression

I've always wanted to make a copy of the LIST. Just haven't had the energy to do it.

LIST.COM is a DOS shareware developed by the late Vernon D. Buerg. This tool is one of the powerful tools when I do reverse TWAY. Well, it's not doing reverse by myself, it's just a file lister.

About the configuration file of bgo

Supports multiple formats

Also derived from the support provided by cmdr, bgo can automatically recognize json, toml and yml (or yaml) suffixes.

That is, in a working directory, it is OK to have .bgo.yml or .bgo.toml. Although our examples always use yaml to show you how to write it, changing it to a different file format will work just as well. And bgo or cmdr will automatically load them.

configuration folder

You've noticed that we provide $HOME/.bgo under 061ff47ca0a672 and 80.aliases.yml in subdirectory conf.d within it.

According to the convention of cmdr, there must be a configuration file with the same name (ie bgo ) in a configuration file directory, and the suffix should be one of .json.toml.yml.yaml. The configuration files of cmdr are divided into three types: primary, secondary and alternative.

For bgo, $HOME/.bgo is a possible location for the primary configuration file group, bgo and cmdr will automatically search several predefined locations (including /usr/local/etc/bgo and $HOME/.bgo ) to try to load the primary configuration file, and then use its conf.d as a watch folder, and load any .json.toml.yml.yaml in it.

So it doesn't matter if you mix different configuration file formats.

conf.d auto configuration folder

In the main configuration file directory, the conf.d subdirectory is monitored, and any configuration files in it can be automatically reloaded. Of course, auto-reloading doesn't make sense for bgo.

But you can add a series of configuration files in this folder, such as alias-001.yml, alias-002.yml. This structure is very convenient for ci operations or devops operations, you don't need to rack your brains to script to add a large yaml fragment to a yaml, but also ensure that they are embedded in the appropriate position and indented at the appropriate level. Just add a yml directly.

auxiliary configuration file

As for .bgo.yml in the current working directory, it is loaded as the identity of the Alternative/Secondary configuration file group.

According to the convention of cmdr, if .bgo.yml is loaded as an alternative configuration file, this configuration file does not contain subfolder monitoring, and the automatic configuration file write-back function can be turned on. However, this feature is not turned on in bgo, because the write-back function will erase the comment section in the configuration file, which may not often be what you want.

The reason why the identity is uncertain is that cmdr supports loading three sets of configurations from the three locations of Primary/Seconary/Alternative at the same time and merging them together. Although we don't specify it, bgo leaves many possibilities for expansion here.

Switch to a different format at bgo init

Different configuration file formats can be created using the following syntax:

bgo init --output=.bgo.yml
bgo init --output=.bgo.yaml
bgo init --output=.bgo.json
bgo init --output=.bgo.toml

The suffix of the output filename determines which configuration file format the initialization operation will store the scan results in.

postscript

Current problems with bgo:

• There is no robust test under Windows, so it is not certain that the load location of the configuration file is effectively recognized.

• The bash shell in the configuration file may be changed to powershell or cmd in windows? I don't really know, maybe it needs a little tweaking to work.

  • FEEL FREE TO ISSUE ME

I mentioned it last time, but this time it was a sudden thought and I did it directly. Then I went to goxc when I found time, ouch, I'll go

Look, everyone just stopped.

Suddenly I feel like the future is meowing.

Why do I think go build cross-compilation is not so simple, or it is very troublesome. Alas, never mind, bgo is such a tool anyway.

REFs

• Project: https://github.com/hedzr/bgo
• Dependencies: https://github.com/hedzr/cmdr
• Example configuration file: https://github.com/hedzr/bgo/blob/master/.bgo.yaml
• go.dev: here
• Docker Hub： hedzr/bgo - Docker Image - Docker Hub

🔚