Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use version from module and another version in matrix testing #450

Open
Jacalz opened this issue Jan 6, 2024 · 2 comments · May be fixed by #489
Open

Use version from module and another version in matrix testing #450

Jacalz opened this issue Jan 6, 2024 · 2 comments · May be fixed by #489
Labels
feature request New feature or request to improve the current logic

Comments

@Jacalz
Copy link

Jacalz commented Jan 6, 2024

Description:
Describe your proposal.

I want to be able to do something like this where the used Go versions are set automatically in matrix testing without having to manually maintain the workflows. This is very useful when having many repositories with CI/CD infrastructure set up. To minimize the versions of Go used for testing, I want to test with the latest stable and the minimum version that the project supports, i.e. I want to use stable and the version from my go.mod file.

My idea is to be able to specify something like go-version-file inside the go-version field:

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        go: [ 'go.mod', 'stable' ]
    name: Go ${{ matrix.go }} sample
    steps:
      - uses: actions/checkout@v4
      - name: Setup go
        uses: actions/setup-go@v4
        with:
          go-version: ${{ matrix.go }}
      - run: go run hello.go

Justification:
Justification or a use case for your proposal.

This is very useful when having many repositories with CI/CD infrastructure set up. To minimize the versions of Go used for testing, I want to test with the latest stable and the minimum version that the project supports, i.e. I want to use stable and the version from my go.mod file.

Are you willing to submit a PR?

Sorry. I'll let you handle this

@Jacalz Jacalz added feature request New feature or request to improve the current logic needs triage labels Jan 6, 2024
@aparnajyothi-y
Copy link

Hello @Jacalz,
Thank you for creating this issue, we will investigate it and come back to you as soon as we have some feedback.

@ardnew
Copy link

ardnew commented Aug 15, 2024

You can achieve this using a secondary job in your workflow to construct the build matrix for your actual build job. I just worked through this myself:

# Triggered on every push or pull request event to any branch.
name: 'test(any): all'
on: { push, pull_request }
jobs:

  # Run `go list` to resolve the module's declared Go version
  # and store the result in ${{ outputs.version }}.
  go-mod-version:
    runs-on: ubuntu-latest
    outputs:
      version: ${{ steps.list.outputs.version }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version-file: 'go.mod'
      - id: list
        run: |
          go list -m -f 'version={{.GoVersion}}' >> "${GITHUB_OUTPUT}"

  # Run all tests in all packages, and record coverages,
  # on latest versions of Ubuntu, macOS, and Windows
  # using Go module version and other notable releases.
  build:
    needs: [ go-mod-version ]
    strategy:
      matrix:
        os: [ ubuntu, macos, windows ]
        go: [ '1.13', '1.19', "${{ needs.go-mod-version.outputs.version }}" ]
        include: [ version: latest ]
    runs-on: ${{ matrix.os }}-${{ matrix.version }}
    name: |
      Go ${{ matrix.go }} (${{ matrix.os }}-${{ matrix.version }})
    env:
      coverprofile: 'cover.out'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: ${{ matrix.go }}
      - name: Build
        run: |
          go build -v ./...
      - name: Test
        run: |
          go test -v -covermode=count -coverprofile="${coverprofile}" ./...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants