circleci-public/go-orb

Go (Golang) Orb

A Go Orb for CircleCI. This orb allows you to do common Go related tasks on CircleCI such as install Go, downloading modules, caching, etc.

Usage

Example usage as well as a list of available executors, commands, and jobs are available on this orb's registry page.

Resources

CircleCI Orb Registry Page - The official registry page for this orb will all versions, executors, commands, and jobs described.
CircleCI Orb Docs - Docs for using and creating CircleCI Orbs.

Contributing

We welcome issues and pull requests against this repository! For further questions/comments about this or other orbs, visit the Orb Category of CircleCI Discuss.

Publishing

New versions of this orb are published by pushing a SemVer git tag by the Community & Partner Engineering Team.

go-orb's Issues

CI needs to deploy destructured orb

Add issue and pull request template

We could add this to have consistency across all other orbs project
I would like to pick this up. Please consider adding the orbtoberfest label on the issue

Default branch needs renaming

Doesn't support `arm64`

Go maps x86_64 to amd64 and the orb does that conversion correctly; however, aarch64 is not correctly mapped to arm64 yielding a 404 when trying to download on an arm executor.

Utilize next-gen convenience image

Does the caching actually works by default?

hey @felicianotech !

I'm not a golang guy, but I'm trying to build setup for a go-based project.

I'm struggling with caching right now, as I see that when "restore cache" step kicks in, the output is pretty much the same all the time:

Found a cache from build 4424 at go-mod-dp7+cumnSitrbWvycofIdkqN1rYyAJhzy06GVfbq3_Y=
Size: 32 B
Cached paths:
  * /home/circleci/project/$GOPATH/pkg/mod

I thought that this was my mistake, but 32 B doesn't seem to be a valid size, is it? I've found out that the integration tests provided in your repo prints out a similar output.

Can you confirm whether it's a bug or not?

Cheers Ricardo, thanks for your work on this orb anyway! 💪

odd build problem with cached Go 1.17.6 executable

I have a CI job that runs on a machine executor and installs Go with the go/install command from the Go orb.

I was previously using Go 1.16.10 and everything was working fine. Then I changed the Go version to 1.17.6, and even though the Go install step still seemed to work, as soon as I tried to build some Go code I got errors like this:

/usr/local/go/src/runtime/internal/sys/stubs.go:9:7: PtrSize redeclared in this block
	/usr/local/go/src/runtime/internal/sys/arch.go:24:38: previous declaration
/usr/local/go/src/runtime/internal/sys/stubs.go:10:24: undefined: Uintreg
/usr/local/go/src/runtime/internal/sys/stubs.go:16:7: StackGuardMultiplier redeclared in this block
	/usr/local/go/src/runtime/internal/sys/arch.go:27:74: previous declaration

Online advice like this generally agreed that this meant a corrupt Go installation, possibly due to not removing a previous installation. So, I tried setting the cache-key parameter to bust the cache so there couldn't be any previous installation. That fixed the build... at least, until the next time I ran it, at which point it failed again.

It looks to me like this failure is correlated with whether the Go orb is reusing a cached version of /usr/local/go/bin/go or not. I don't see how it could be caching an invalid executable, because in the previous test run that succeeded, it was using that very same executable. But, so far, this is very reproducible and I can't get the build to stay green except by setting cache: false.

Make cache file path a configurable variable [continued]

#33 made cache save configurable, but not cache load.

Also, what do you think about using $GOPATH instead of hardcoding the directory?

E.g something like

    default: "${GOPATH}/pkg/mod"

I'm trying to do this without success:

      - go/load-cache:
          path: /root/go/pkg/mod
      - run: make mod
      - go/save-cache:
          path: /root/go/pkg/mod

where make mod does a go mod download with some PROXY stuff and then a go mod tidy

The install command installs a Linux binary on macOS

Destructure Orb

Destructure the orb to more easily add components in the future.
https://circleci.com/docs/2.0/local-cli/#packing-a-config

This can also be accomplished with the Orb Starter Kit:
https://github.com/CircleCI-Public/orb-starter-kit

feat: Allow `test` job to support JUnit test output

We use the Go orb to simplify some of our Golang repo mechanics, but we don't use the test job because it doesn't let us specify JUnit output.

We like getting the JUnit output because it intentionally uses the features of CircleCI to better elevate our test results, and gives us data in Test Insights.

For example, rather than using the orb out of the box right now,

- go/test:
    covermode: atomic
    failfast: true
    race: true

which provides no test output. Instead, we use a regular command and run:

- run:
    command: gotestsum --junitfile test-results/unit-tests.xml -- -covermode=atomic -coverprofile=test-results/coverage.out

And then using:

 - store_test_results:
           path: test-results

Would be great if there was a flag to pass into the test job to sort of do this "automatically" within the test job.

Add macOS executor support

Doesn't support version `1.21`

Error Log:

Installing the requested version of Go.
curl: (22) The requested URL returned error: 404

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now

Exited with code exit status 2

Seems like this URL will respond a 404 https://dl.google.com/go/go1.21.linux-amd64.tar.gz.
But https://dl.google.com/go/go1.20.linux-amd64.tar.gz will not.

Misleading documentation on test.parallel

The parallel parameter is currently described here as setting the go test -parallel flag, but it is instead setting the -p flag here - which is confusingly an entirely different setting that does not control the number of parallel tests within a package (t.Parallel), but the number of distinct test binaries that can be ran in parallel.

Allow parallel execution of test functions that call t.Parallel. The value of this flag is the maximum number of tests to run simultaneously

Relevant excerpt from go help testflag

        -parallel n
            Allow parallel execution of test functions that call t.Parallel,
            ...
            By default, -parallel is set to the value of GOMAXPROCS.
            ...
            Note that -parallel only applies within a single test binary.
            The 'go test' command may run tests for different packages
            in parallel as well, according to the setting of the -p flag
            (see 'go help build').

And for go help build

        -p n
                the number of programs, such as build commands or
                test binaries, that can be run in parallel.
                The default is GOMAXPROCS, normally the number of CPUs available.

I'm not sure what the right move here is for this project, but IHMO -p 1 is an inappropriate default

incorrect hosttype on arm ubuntu machine images

given the following:

jobs:
  build:
    machine:
      image: ubuntu-2204:2022.10.2
    resource_class: arm.medium
    steps:
      - checkout
      - go/install:
          version: 1.19.3

It fails as curl returns 404.

Issue seems to be due to $HOSTTYPE being set as aarch64 which does go binary not existing at https://dl.google.com/go/go1.19.3.linux-aarch64.tar.gz

Utilize new cimg docker image executor

https://github.com/CircleCI-Public/go-orb/blob/master/orb.yml#L14

Update language orbs to utilize the new cimg

Dockerhub: https://hub.docker.com/u/cimg
cimg beta announcement: https://discuss.circleci.com/t/new-convenience-image-alpha-preview-ready-for-testing/31364

Ensure tags are parameterized.

Any PRs made in service of this issue will be held until cimg docker images are ready for release.

Make cache file path a configurable variable

Set issue with executor 1.19

Circle file:

version: 2.1

orbs:
  go: circleci/go@1

jobs:
  test:
    executor:
      name: go/default
      tag: '1.19'
    steps:
      - checkout
      - go/load-cache
      - go/mod-download
      - go/save-cache
      - go/test:
          covermode: atomic
          failfast: true
          race: true
workflows:
  version: 2
  janus-pipeline:
    jobs:
      - test:
          context: cambia

Circle job failing with:

/bin/bash: line 9: set: -c: invalid option
set: usage: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...]

When using go/install with cache:true, existing installation is not properly cleaned

Hello @felicianotech ! I've been trying to set-up CI for a project and I encountered the following issue

We are using a machine executor and then trying to install go through the command provided by the orb:

machine:
  image: ubuntu-2004:202101-01
steps:
    - checkout
    - go/install:
        cache: true
        version: 1.16.3

Without using the cache, the install script properly cleans the existing go installation (1.15.6 if I remember well) before installing the new version.
But if we set cache:true it seems it is not getting cleaned properly as we get this kind of errors when using go after:

/usr/local/go/src/runtime/mgcsweepbuf.go:87:80: memstats.gc_sys undefined (type mstats has no field or method gc_sys)
/usr/local/go/src/runtime/mgcsweepbuf.go:106:102: memstats.gc_sys undefined (type mstats has no field or method gc_sys)

Which refers to a file removed in go 1.16, and is symptomatic of a badly cleaned installation.

Would it be possible to properly clean the existing installation when using the cached go binary ? It might be on purpose to avoid some other issues I am not aware of.

`go/test` with no parameters fails on versions > 1.7.1

Hiya! My job looks like:

  test_golang:
    executor:
      name: go/default
      tag: "1.21"
    steps:
      - checkout:
      - go/load-cache
      - go/mod-download
      - go/save-cache
      - go/test

and I get this error

+ go test -count=1 -coverprofile=cover-source.out -p 1 -covermode=set ./... -coverpkg=./... -race -failfast -short -v
-covermode must be "atomic", not "set", when -race is enabled

Exited with code exit status 1

on any version > 1.7.1

Needs Orb Tools 11 (running v9)