I’m spending some time trying to better understand best practices for Golang Modules and when used with GitHub’s Dependabot.

One practice I’m pursuing is to not (GitHub) Release Go Modules in separate repos that form part of a single application. In my scenario, I chose to not use a monorepo and so I have an application smeared across multiple repos. See GitHub help with dependency management

If a Module is not Released (on GithUb) then the go tooling versions the repo as:

gcloud container clusters create is a complex command. The --cluster-version flag, often combined with --release-channel in order to have Google maintain the master and node versions, take values that are provided by gcloud container get-server-config.

The available Kubernetes versions differs by region and by zone:

gcloud container get-server-config \
--project=${PROJECT} \
--zone=us-west2-c

Yields:

channels:
- channel: RAPID
  defaultVersion: 1.21.3-gke.2001
  validVersions:
  - 1.21.4-gke.301
  - 1.21.3-gke.2001

Whereas:

gcloud container get-server-config \
--project=${PROJECT} \
--region=us-west2

Yields

channels:
- channel: RAPID
  defaultVersion: 1.21.4-gke.301
  validVersions:
  - 1.21.4-gke.1801
  - 1.21.4-gke.301

I assume the divergence results from a controlled rollout of Kubernetes versions across regions and zones.

gcloud container images list --project=${PROJECT} does warn (!) but it’s easy to ignore that it only includes result for gcr.io and not any other subdomain (e.g. us.gcr.io):

gcloud container images list \
--project=${PROJECT}

NAME
gcr.io/${PROJECT}/endpoints-runtime-serverless
Only listing images in gcr.io/${PROJECT}. Use --repository to list images in other repositories.

gcloud container images list \
--repository=us.gcr.io/${PROJECT}

NAME
us.gcr.io/${PROJECT}/foo
us.gcr.io/${PROJECT}/bar
us.gcr.io/${PROJECT}/baz

NOTE Because the repository is explicitly us.gcr.io/${PROJECT}, it does not include the previous endpoints-runtime-serverless because that image is in gcr.io.

I continue to be “challenged” grep’ing my Golang GitHub repos to check for module updates. I feel my code aging in cold storage and it bugs me.

Golang issues 40364: enable listing direct dependency updates includes this useful solution which filters indirect dependencies and returns a list of direct dependency updates (although presumably only 0–>1 for major versions):

go list -f '{{if not .Indirect}}{{.}}{{end}}' -u -m all

I’ll take what I can get.

PROJECTS=$(\
  gcloud projects list \
  --format='csv[no-heading,terminator=","](projectId)') && \
PROJECTS="${PROJECTS%,}" && \  
echo ${PROJECTS}

From:

gcloud projects list
PROJECT_ID    NAME          PROJECT_NUMBER
foo           foo           1234567890123
bar           bar           1234567890123
baz           baz           1234567890123

To:

foo,bar,baz

Which you may find useful when you need to pass a list of Project IDs to some command-line flag.

A smörgåsbord of guidance involving Golang modules, private repos and containers. Everything herein is documented elsewhere (I’ll provide links) but I wanted to consolidate the information primarily for my own benefit.

GOPRIVATE

Using private modules adds complexity because builders need to be able to access private modules. Customarily, as you’re hacking away, you’ll likely not encounter issues but, when you write a Dockerfile or develop some CI, you’ll encounter something of the form:

I’m using Pushover’s (generous) 30-day trial. IIUC thereafter (for personal use) the app’s $5 for a perpetual license. That seems very reasonable to me.

I find Prometheus’ documentation “light”. Everything’s there but the docs feel oriented to the power|frequent user. I use Prometheus infrequently and struggle to understand the docs.

The AlertManager configuration for Pushover is ok but I struggled to understand the reference to (Golang) templates:

# Notification title.
[ title: <tmpl_string> | default = '{{ template "pushover.default.title" . }}' ]

# Notification message.
[ message: <tmpl_string> | default = '{{ template "pushover.default.message" . }}' ]

# A supplementary URL shown alongside the message.
[ url: <tmpl_string> | default = '{{ template "pushover.default.url" . }}' ]

I’m familiar with the Go’s templating but I was unclear how to interpret these configuration references. As I thought it, I assumed these must reference default templates (shipped with AlertManager) and found these here:

I was frustrated to discover a phantom service bound to port 8080.

If I browsed localhost:8080 in Chrome, I received a mostly blank screen that recalled when I’d used the WebThings gateway:

And the process responded to /metrics requests too:

I was flummoxed because I was not expecting this process to be running, could not find (and so could not kill it) and became concerned that it was something more nefarious:

Environment

There are several ways to consume environment variables in GitHub Actions but I was unsure how to set environment variables. I have a Go build that uses -ldflags "-X main.OSVersion=${VERSION} -X main.GitCommit=${COMMIT}" to set variables in the binary that can be e.g. exported via Prometheus.

The GitCommit is straightforward as it’s one of GitHub Actions’ provided values and is just ${{ github.sha }}.

I wanted to set Version to be the value of uname --kernel-release. Since the build is using ubuntu-latest, this is easy to get but, how to set?

This is documented but, for some reason, I always forget it.

Visual Studio Code is awesome and, in particular when debugging, it’s useful to set environment variables.

I write a lot of Google Cloud code and so I’m frequently wanting:

launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            ...
            "env": {
                "GOOGLE_APPLICATION_CREDENTIALS": "...",
                "PROJECT": "...",
            }
        }
    ]
}

And, through a combo of forgetfulness and laziness, I tend to duplicate the values from the host environment as strings in these files.