# Update Gin Dependencies Every Week

Yes. Each week an agent runs go get -u in groups, tests and lints after each, and opens one pull request listing every bump taken and each one left out with why.

[Run this on Rush](https://cloud.getrush.ai/run/update-dependencies/gin/), in a Project that has your repository.

## What the agent does

The agent reads what the module depends on and how the project proves itself. In a Gin API like gothinkster/golang-gin-realworld-example-app, `go.mod` declares `go 1.21` and eight direct requirements: `gin-gonic/gin` v1.10.0, `go-playground/validator/v10` v10.24.0, `golang-jwt/jwt/v5` v5.2.1, `gosimple/slug` v1.15.0, `stretchr/testify` v1.10.0, `golang.org/x/crypto` v0.32.0, `gorm.io/gorm` v1.25.12 and `gorm.io/driver/sqlite` v1.5.7. The readme's dependency table adds the project's own notes on each: gorm v1.30 and later has breaking changes, validator v10.30 and later requires Go 1.24, gin v1.11 adds experimental HTTP/3, the sqlite driver needs cgo. `.github/workflows/ci.yml` tests on a matrix of Go 1.21, 1.22 and 1.23, runs `go mod verify`, `scripts/gofmt.sh` and `scripts/coverage.sh` (a per-package `go test -coverprofile` loop), lints with golangci-lint v1.61 using `.golangci.yml` (staticcheck, unused, misspell), scans with gosec, and runs the RealWorld Postman collection with Newman against a built binary on port 8080.

Those constraints decide the groups. First `go get -u=patch ./...` for patch releases, then minors, then each major or each requirement whose newer versions raise the Go floor on its own. After every group the agent runs `go mod tidy`, `go build ./...`, `go vet ./...`, `go test ./...` across the 63 test functions in `articles/unit_test.go`, `users/unit_test.go` and `common/unit_test.go` (they use `common.TestDBInit()` and `TestDBFree()` against SQLite at `TEST_DB_PATH`, `httptest` and testify), `bash scripts/gofmt.sh`, and `golangci-lint run` at the pinned version when it is available in the sandbox. A group that passes is committed; a group that fails is reverted and the failure recorded.

The Go floor is where this module's upgrades bite. The CI matrix starts at Go 1.21, so a validator release that needs Go 1.24 cannot be taken without changing `go.mod`'s `go` directive and the workflow matrix, and the prompt says to leave out what breaks rather than widen the change. The same applies to a gorm minor that the readme flags as breaking: if `Preload`, `Updates` or `Count` behaviour shifts and a test in `articles/unit_test.go` fails, the bump is reverted and the test name and error are kept for the description. `golang.org/x/crypto` and `x/net` are taken whenever they build, because the readme asks for them to be kept current for security fixes.

The pull request has one commit per group so a reviewer can drop one without losing the rest. Its description lists each requirement with old and new version, the test and lint commands run after each group, and a section of upgrades left out with the exact failure or the Go-version reason. `go.sum` changes only by what `go mod tidy` produced; no source file changes unless a bump required a one-line adaptation, which is called out.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Update this Go module's dependencies with go get -u in groups: patch releases together, then minor releases together, then each major version or any requirement whose newer release raises the module's Go version on its own. After each group run go mod tidy, go build ./..., go vet ./..., go test ./..., bash scripts/gofmt.sh and golangci-lint run if available. Keep a group only if everything passes; otherwise revert it and record the failing test or error. Do not change the go directive or the CI matrix. Open one pull request with one commit per group whose description lists every bump with old and new versions and every upgrade left out with the reason.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

What comes back is a pull request on a new branch touching `go.mod` and `go.sum` only, in one commit per group that passed: patches, minors, and any single-requirement bump that stood on its own. The `go` directive stays at 1.21 and `.github/workflows/ci.yml` is untouched, so the existing matrix runs the checks on the pull request as it does on every other.

The description is a table of requirements with old and new versions, followed by the commands run after each group and their result lines, and a final section listing each upgrade left out with its failing test name and message or the Go version it requires. The trajectory keeps the full `go test` and `golangci-lint` output for every attempt, including the reverted ones.

Before merging, a reviewer checks that `go mod verify` still passes, that the sqlite driver and gorm moved together if both moved, that nothing in the left-out list is a security fix that should be taken by raising the Go version deliberately, and that the Newman API test in CI passed on the pull request, since the unit tests do not exercise the server binary.

## Run it on every Monday morning

Create an automation in the Project with this prompt and a `schedule` trigger (`cron` `0 9 * * 1` with your `timezone`). Each week the run reads the current `go.mod`, takes what has moved, and opens one pull request, or none when nothing changed. Because it never changes the Go directive, the pull request is always within what CI already tests.

Give the API key a webhook URL to receive `run.completed` with the `session_url` and post the pull request link where the backend team looks on Monday. When the left-out list names the same requirement several weeks in a row, that is the signal to raise the Go floor in a separate, deliberate pull request.

## Why run it on Rush?

Weekly `go get -u` on a laptop is a loop of bump, test, read a failure, revert, retry, with the result that nobody does it and the module falls behind on `x/crypto`. On Rush the agent runs that loop in a sandbox with the module's Go toolchain, keeps every test and lint output, and returns one pull request where each group is a separate commit and each failure is written down.

The pull request is proof as well as change: the description quotes what was run and what it said, and the record holds the rest. The same request runs on every Go service you own at once, each in its own sandbox, with the same shape of result.

## Frequently asked questions

### Why not just run go get -u ./... once?

Because one failing bump then hides which requirement broke the build. Grouping patches, minors and majors, and isolating any requirement that raises the Go floor, means each commit is independently revertable and the left-out list names the exact culprit.

### Will it raise the go directive to take a newer validator or gorm?

No. The CI matrix in this project tests Go 1.21 through 1.23, and widening the Go version is a decision for a person. The agent records the requirement and the version it needs so you can make that change in its own pull request.

### Does it run golangci-lint and gosec?

It runs golangci-lint at the version CI pins when it can install it in the sandbox, with the project's `.golangci.yml`. gosec runs in CI on the pull request with `-no-fail`, so the agent leaves it there and says so.

### What about the SQLite driver and cgo?

The sandbox has a C toolchain, so `gorm.io/driver/sqlite` builds and the tests run against a real SQLite file at `TEST_DB_PATH`. A move to a pure-Go driver is a code change, not an upgrade, and is out of scope for this job.

### Does the Postman API test run inside the sandbox?

Only when Node and Newman are available there; otherwise the agent relies on the unit tests and leaves the API test to the CI job, which runs it on the pull request. The description says which happened.