Gain insights into writing professional command-line programs in Go. Delve into structuring Go programs, writing idiomatic code, testing effectively, and impressing users and managers.

write professional command  - line programs in Go.png

data.tar.gz

Go run main.go

Run main.sh

Run go test

Run go test2

GoLive

GoLiveTesting

Multi-git-Custom

Pre+main-v0.2

Main_to_cmd

Run go test-Coverage

Ginkgo

Ginkgo-BDD

Ginkgo-e2e

Cobra

Cobra-NoInstall

Cobra-NoInstall-FullApp

Final_Cobra_Multi-git

Viper

Viper-etcd

Viper-Cobra

SelfUpdating

Make

Special build

Embedding_Data

Go run main.go-Simple

In this course you will learn why Go is an awesome language for writing command-line programs. You will learn how to structure your Go programs, how to write idiomatic Go code, how to test your programs and how to amaze your users, peers and managers. 

The focus is on command-line programs in order to keep the course down to earth, but most of the principles and best practices you will learn apply to any Go program.

Write Professional Command-line Programs in Go


# Creating releases with GitHub Actions

For the purpose of self-updating, we will create official releases when a particular commit is tagged. A good naming convention is to use semantic versioning tags with <major>.<minor>.<build>.

When you are happy with a particular commit you can tag it like so:

```
git tag v0.8.18
```

Pushing the tag is as simple as:

```
git push --tags
```

This will trigger the `Create Release` workflow in `on-tag-push.yml`. Let's review it piece by piece. It is triggered by tags that start with lowercase `v`. This means that you can have additional tags that will not trigger a release.
```
on:
  push:
    # Sequence of patterns matched against refs/tags
    tags:
      - 'v*' # Push events to matching v*, i.e. v1.0, v20.15.10

name: Create Release
```

Next, in the jobs section, it defines a build job whose name is also `Create Release` like the workflow. It runs on `ubuntu-latest` runner and it defines two environment variables that will be available to all the steps of this job. The secrets.GITHUB_TOKEN is needed to access the GitHub API and thanks to the tight integration with GitHub it is provided automatically.

```
jobs:
  build:
    name: Create Release
    runs-on: ubuntu-latest
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions
      COMPRESS_FILES: true

```

Now, come the steps. The first step `Checkout code` uses a built-in action `actions/checkout@v2`. There is no need to configure it because it gets all the context it needs implicitly from the workflow context, including repo, branch, etc.

```
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
```

The next step, is another built-in action, which creates a GitHub release. It requires some input such as the tag name, the release name, the release description (body), and whether it is a draft or pre-release.

```
      - name: Create Release
        id: create_release
        uses: actions/create-release@v1
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}
          body: ${{ github.event.head_commit.message }}
          draft: false
          prerelease: false
```

After this step executes, we will have a GitHub release that contains the source code artifacts. However, we also want multi-git binaries for multiple platforms. In order to do that, we need to cross-compile multi-git. To do this, we can use a custom action called [golang-build](https://github.com/sosedoff/actions/tree/master/golang-build) that I found. Note that it is not available in the community's [Actions Marketplace](https://github.com/marketplace?type=actions), which is a good place to start looking for actions.

```
      - name: Build binaries
        uses: sosedoff/actions/golang-build@master
```

Once the binaries are built, they are available in the `.release` sub-directory of the workflow's workspace. This is just how the golang-build action does it.

The next step is to upload the binaries and add them as assets to the release. We can use the built-in action `actions/upload-release-asset`. The name of each binary follows this naming convention `multi-git_<OS>_<CPU>.zip`.

```
        uses: actions/upload-release-asset@v1
        with:
          # This pulls from the CREATE RELEASE step above, 
          # referencing it's ID to get its outputs object,
          # which include a `upload_url`.

          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: .release/multi-git_darwin_386.zip
          asset_name: multi-git_darwin_386.zip
          asset_content_type: application/zip
```

Unfortunately, upload-release-asset allows uploading one asset at the time, so we need to have a separate step for binary. Here is another step:

```
      - name: Upload multi-git windows_amd64
        id: upload_multi_git_windows_amd64
        uses: actions/upload-release-asset@v1
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: .release/multi-git_windows_amd64.zip
          asset_name: multi-git_windows_amd64.zip
          asset_content_type: application/zip
```

In the end, this is what the release looks like on GitHub:





In this lesson, we'll continue to use GitHub Actions workflows and create Github releases for Multi-git. We will use these releases later to allow multi-git to update itself.

Creating GitHub Releases for Multi-git

Overview

Restructuring multi-git

Testing 1,2,3...

Adding Smart Command-Line Parsing

Adding Advanced Configuration

Adding Bells and Whistles

Summary

Creating GitHub Releases for Multi-git

Creating releases with GitHub Actions