mvdan.cc / cue
this repo has no description
0
fork

Configure Feed

Select the types of activity you want to include in your feed.

internal/ci: include more useful string values in base

Every repository has to repeat "latestGo", which is a bit silly.
It's much easier to update it in one place, and re-run `cue mod get`
across all repositories to get the update.
Do the same with the previous Go release; even though just a few repos
test on a matrix of Go versions, it's still useful as a base value.

Also switch "cueCommand" to use `go tool cue`, which is the default
we're currently switching to. Each repository can still override this,
for example the cue repo as it must still support Go 1.23.
However, the majority of repositories should be nudged in the direction
of Go tool dependencies.

Signed-off-by: Daniel Martí <mvdan@mvdan.cc>
Change-Id: I599e0ea3a6ac1498ce151c66d5af91caad7e7cd1
Reviewed-on: https://cue.gerrithub.io/c/cue-lang/cue/+/1218981
Reviewed-by: Paul Jolly <paul@myitcv.io>
Unity-Result: CUE porcuepine <cue.porcuepine@gmail.com>
TryBot-Result: CUEcueckoo <cueckoo@cuelang.org>

Daniel Martí a78e432f 6d3530bf

+11 -11
+9 -1
internal/ci/base/base.cue
··· 58 58 unprivilegedBotGitHubUser: "not" + botGitHubUser 59 59 unprivilegedBotGitHubUserCentralRegistryTokenSecretsKey: *(strings.ToUpper(unprivilegedBotGitHubUser) + "_CUE_TOKEN") | string 60 60 61 - cueCommand: *"cue" | string 61 + // Most repositories will already be a Go module, so they can use a tool dependency. 62 + // Others can override this string with e.g. `cue` from the `setup-cue` action. 63 + cueCommand: *"go tool cue" | string 62 64 63 65 workflowFileExtension: ".yaml" 64 66 ··· 85 87 // so it's actually fine if we always use "large" MacOS and Windows machines. 86 88 macosMachine: string | *"ns-macos-arm64" 87 89 windowsMachine: string | *"ns-windows-amd64" 90 + 91 + // Use the latest Go version for extra checks, 92 + // such as running tests with the data race detector. 93 + latestGo: "1.24.x" 94 + // Some repositories also want to ensure that the previous version works. 95 + previousGo: "1.23.x" 88 96 89 97 codeReview: #codeReview & { 90 98 github: githubRepositoryURL
+1 -1
internal/ci/github/trybot.cue
··· 89 89 _testStrategy: { 90 90 "fail-fast": false 91 91 matrix: { 92 - "go-version": _repo.matrixGo 92 + "go-version": [_repo.previousGo, _repo.latestGo] 93 93 runner: [_repo.linuxMachine, _repo.macosMachine, _repo.windowsMachine] 94 94 } 95 95 }
+1 -9
internal/ci/repo/repo.cue
··· 29 29 // The tests on this repository are pretty CPU-intensive. 30 30 linuxMachine: base.linuxLargeMachine 31 31 32 - // Use the latest Go version for extra checks, 33 - // such as running tests with the data race detector. 34 - // This may be a release candidate if we are late into a Go release cycle. 35 - latestGo: "1.24.x" 36 - 37 - // The list of all Go versions that we run our tests on. 38 - // This typically goes back one major Go version, as we support two at a time. 39 - matrixGo: ["1.23.x", latestGo] 40 - 41 32 // Use a specific latest version for release builds. 42 33 // Note that we don't want ".x" for the sake of reproducibility, 43 34 // so we instead pin a specific Go release. ··· 63 54 64 55 codeReview: "cue-unity": unityRepositoryURL 65 56 57 + // TODO: we can't use `go tool cue` yet. 66 58 cueCommand: "go run cuelang.org/go/cmd/cue"