Build both go-1.13 and go-1.14 in circleci

[evantorrie]

Per gitter.im discussion re: support for at least two most recent versions of go, this PR changes the circleci build config to build the project in both go-1.13 and go-1.14 versions.

[lizthegrey]

The current branch protections require ci/circleci: build to complete. You'll want to add a new job named build that depends upon both go-1.13 and go-1.14 so that we can adjust version numbers without having to change branch protection going forward.

Possible checks github will let me set required:

 ci/circleci: build
 ci/circleci: go-1.13
 ci/circleci: go-1.14

[evantorrie]

@lizthegrey Done. I'm a CircleCI neophyte - this could likely be done better using v2.1 commands etc - but does seem to work for now.

[jmacd]

It looks like the build stanza doesn't need the image here, is that right? (Not that it hurts.)

[krnowak]

I have been reading the CircleCI docs and every job needs to specify an executor (docker, machine, macos or windows). So even if we want an empty build, we need to have an executor. And docker executor requires specifying the image name.

So maybe instead of having three jobs (build, go-1.13 and go-1.14) how about we have two jobs - build and old-go-build? The build job could depend on the old-go-build job. That way, if the new version of go is released, all we need to update is docker image names. Job names will stay the same. Dependencies stay the same.

[krnowak]

I think we could limit the number of jobs to 2 and limit having places where we specify go version to docker image names.

[krnowak]

I have been reading the CircleCI docs and every job needs to specify an executor (docker, machine, macos or windows). So even if we want an empty build, we need to have an executor. And docker executor requires specifying the image name.

So maybe instead of having three jobs (build, go-1.13 and go-1.14) how about we have two jobs - build and old-go-build? The build job could depend on the old-go-build job. That way, if the new version of go is released, all we need to update is docker image names. Job names will stay the same. Dependencies stay the same.

[evantorrie]

I think we could limit the number of jobs to 2 and limit having places where we specify go version to docker image names.

We could do the "current-go"/"prior-go" but I think the "requires" directive would result in the two builds running sequentially - effectively doubling the build time, whereas in reality the two builds are independent.

[evantorrie]

I've changed this to use pre-defined executors and parametrizable jobs to enable just two "names-without-versions" jobs:

current-go
prior-go

The build workflow requires both of these to pass.

Each job can be changed simply by bumping up the version for each of the predefined executors when a new version of go is released.

@lizthegrey Does this change what you see in the required checks that the CircleCI/github integration provides? I removed the "build" job and now have the workflow that builds the source on both the current and prior versions of go called build. According to this CircleCI doc page,

• "Having the ci/circleci:build checkbox enabled will prevent the status from showing as completed in GitHub when using a GitHub Checks because CircleCI posts statuses to GitHub at a workflow level rather than a workflow job level."

At least when I tried this new method on my own repository, I now see a checkbox in the Branch Protections called just build corresponding to the name of the workflow, and selecting this seems to correspond to the build workflow succeeding.

Once again, I'm only running into CircleCI for the second time, so if this doesn't work or there are better ways to achieve this (I do see a lot of people requesting TravisCI like matrix builds in their forums), let me know.

[krnowak]

This looks very nice, thanks! But I think some config somewhere needs to be updated, because we can see now that github is waiting for the nonexistent "build" job.

[evantorrie]

This looks very nice, thanks! But I think some config somewhere needs to be updated, because we can see now that github is waiting for the nonexistent "build" job.

Yes, that's my question to @lizthegrey above. On my test repo, after I started using this new configuration, a new "check" type showed up on my protected branch page with just the title build (corresponding to the name of the workflow I believe). It seems the checks which are prefixed with ci/circleci: correspond to the names of individual jobs. With this configuration, we have a build workflow, but we do not have a build job.

[rghetia]

This looks very nice, thanks! But I think some config somewhere needs to be updated, because we can see now that github is waiting for the nonexistent "build" job.

Yes, that's my question to @lizthegrey above. On my test repo, after I started using this new configuration, a new "check" type showed up on my protected branch page with just the title build (corresponding to the name of the workflow I believe). It seems the checks which are prefixed with ci/circleci: correspond to the names of individual jobs. With this configuration, we have a build workflow, but we do not have a build job.

wouldn't s/current-go/build/ in circle-ci config solve the problem?

[evantorrie]

wouldn't s/current-go/build/ in circle-ci config solve the problem?

Yes, it would, but based on the CircleCI docs, it seems they would prefer users of these checks move to using workflow names rather than job names. Just wanted to see what showed up on the Branch Protection "Checks" page.

[lizthegrey]

I can address the branch protections no problem.

[jmacd]

@lizthegrey can you advise on this? I'm not sure what is needed.

[lizthegrey]

https://github.com/open-telemetry/opentelemetry-go/settings/branch_protection_rules/5356663 updated, re-running the tests and will merge.

[lizthegrey]

Verified the cache settings work now.