search

atc0005 / todo

A collection of TODO items not specific to any one project
MIT License
0 stars 0 forks source link

Pull Requests are not triggering `go mod tidy` and `go mod vendor` checks #51

Closed atc0005 closed 1 year ago

atc0005 commented 1 year ago

Overview

While reviewing an offered Pull Request for a project that I maintain, I found some of the CI failures to be unclear.

Example:

example_constants_test.go:28:10: undeclared name: `nagios` (typecheck)
    os.Exit(nagios.StateOKExitCode)
            ^
example_constants_test.go:34:3: undeclared name: `nagios` (typecheck)
        nagios.StateOKLabel,
        ^
example_constants_test.go:35:3: undeclared name: `nagios` (typecheck)
        nagios.CheckOutputEOL,
        ^
Error: Process completed with exit code 1.

Looking at other jobs I realized what the real problem was:

Run go test -mod=vendor -v ./...
# github.com/atc0005/go-nagios
FAIL    github.com/atc0005/go-nagios [setup failed]
nagios_test.go:6:2: cannot find package "." in:
FAIL
    /__w/go-nagios/go-nagios/vendor/github.com/stretchr/testify/assert
Error: Process completed with exit code 1.

The contributor was adding a dependency to the project (stretchr/testify for their test cases), but did not vendor the dependency before submitting their PR.

The current CI failures do not indicate that this is expected.

The go mod tidy and go mod vendor checks are handled here:

  go_mod_changes:
    name: Look for uncommitted Go module changes
    runs-on: ubuntu-latest
    timeout-minutes: 10
    container:
      image: ghcr.io/atc0005/go-ci:go-ci-lint-only

    steps:
      - name: Check out code
        uses: actions/checkout@v3.3.0

      - name: go mod tidy
        run: |
          go mod tidy
          git diff --exit-code go.mod

      - name: go mod vendor
        run: |
          go mod vendor
          git diff --exit-code

This job is included by importing workflows like this one:

name: Push Validation

# Run jobs when someone pushes to a repository branch. This workflow is
# intended to provide quick validation of content changes for Pull Requests
# (new, updated).
on:
  push:

jobs:
  quick_validation:
    name: Quick
    uses: atc0005/shared-project-resources/.github/workflows/quick-validation.yml@master

The end result is that these steps only run for code pushed to a branch that lives in the project's repo. As I'm the primary contributor to projects that I maintain and am the sole contributor pushing to branches in those repos I didn't catch this "gotcha" until this most recent PR.

I'll plan to either mirror the jobs (duplication), or (more likely) import the quick-validation.yml file into another workflow file so that the go mod tidy and go mod vendor steps run early in the CI jobs process when Pull Requests are submitted.

As of this moment I'm not sure how to pull that off (cleanly) without touching the workflow files in each project (which I was hoping to prevent).

TODO

Update each project's copy of the project-analysis.yml file to include two additional jobs:

  go_mod_validation:
    name: Go Module Validation
    uses: atc0005/shared-project-resources/.github/workflows/go-mod-validation.yml@master

  dependency_updates:
    name: Dependency Updates
    uses: atc0005/shared-project-resources/.github/workflows/dependency-updates.yml@master

This enables the following steps:

By adding these jobs to the existing project-analysis.yml workflow file they're executed on Pull Requests (new, updated) and on the existing weekly schedule.

The expected runtime impact is low.

Along with these changes is the need to update the existing "Branch protection rule" for this project. GH-52 will track that work.

References

atc0005 commented 1 year ago

PRs opened in all applicable projects.

I will need to go back and review the CI results once all jobs complete and merge before closing this GH issue.

atc0005 commented 1 year ago

PRs opened in all applicable projects.

I will need to go back and review the CI results once all jobs complete and merge before closing this GH issue.

Done.