Skip to content

chore(deps): update module github.com/golang-jwt/jwt/v4 to v5#1475

Open
red-hat-konflux[bot] wants to merge 1 commit into
mainfrom
konflux/mintmaker/main/github.com-golang-jwt-jwt-v4-5.x
Open

chore(deps): update module github.com/golang-jwt/jwt/v4 to v5#1475
red-hat-konflux[bot] wants to merge 1 commit into
mainfrom
konflux/mintmaker/main/github.com-golang-jwt-jwt-v4-5.x

Conversation

@red-hat-konflux

@red-hat-konflux red-hat-konflux Bot commented Feb 25, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
github.com/golang-jwt/jwt/v4 v4.5.2v5.3.1 age confidence

Warning

Some dependencies could not be looked up. Check the warning logs for more information.


Release Notes

golang-jwt/jwt (github.com/golang-jwt/jwt/v4)

v5.3.1

Compare Source

What's Changed
🔐 Features
👒 Dependencies
New Contributors

Full Changelog: golang-jwt/jwt@v5.3.0...v5.3.1

v5.3.0

Compare Source

This release is almost identical to to v5.2.3 but now correctly indicates Go 1.21 as minimum requirement.

What's Changed

Full Changelog: golang-jwt/jwt@v5.2.3...v5.3.0

v5.2.3

Compare Source

What's Changed

New Contributors

Full Changelog: golang-jwt/jwt@v5.2.2...v5.2.3

v5.2.2

Compare Source

What's Changed

New Contributors

Full Changelog: golang-jwt/jwt@v5.2.1...v5.2.2

v5.2.1

Compare Source

What's Changed

New Contributors

Full Changelog: golang-jwt/jwt@v5.2.0...v5.2.1

v5.2.0

Compare Source

What's Changed

New Contributors

Full Changelog: golang-jwt/jwt@v5.1.0...v5.2.0

v5.1.0

Compare Source

What's Changed

New Contributors

Full Changelog: golang-jwt/jwt@v5.0.0...v5.1.0

v5.0.0

Compare Source

🚀 New Major Version v5 🚀

It's finally here, the release you have been waiting for! We don't take breaking changes lightly, but the changes outlined below were necessary to address some of the challenges of the previous API. A big thanks for @​mfridman for all the reviews, all contributors for their commits and of course @​dgrijalva for the original code. I hope we kept some of the spirit of your original v4 branch alive in the approach we have taken here.
~@​oxisto, on behalf of @​golang-jwt/maintainers

Version v5 contains a major rework of core functionalities in the jwt-go library. This includes support for several validation options as well as a re-design of the Claims interface. Lastly, we reworked how errors work under the hood, which should provide a better overall developer experience.

Starting from v5.0.0, the import path will be:

"github.com/golang-jwt/jwt/v5"

For most users, changing the import path should suffice. However, since we intentionally changed and cleaned some of the public API, existing programs might need to be updated. The following sections describe significant changes and corresponding updates for existing programs.

Parsing and Validation Options

Under the hood, a new validator struct takes care of validating the claims. A long awaited feature has been the option to fine-tune the validation of tokens. This is now possible with several ParserOption functions that can be appended to most Parse functions, such as ParseWithClaims. The most important options and changes are:

  • Added WithLeeway to support specifying the leeway that is allowed when validating time-based claims, such as exp or nbf.
  • Changed default behavior to not check the iat claim. Usage of this claim is OPTIONAL according to the JWT RFC. The claim itself is also purely informational according to the RFC, so a strict validation failure is not recommended. If you want to check for sensible values in these claims, please use the WithIssuedAt parser option.
  • Added WithAudience, WithSubject and WithIssuer to support checking for expected aud, sub and iss.
  • Added WithStrictDecoding and WithPaddingAllowed options to allow previously global settings to enable base64 strict encoding and the parsing of base64 strings with padding. The latter is strictly speaking against the standard, but unfortunately some of the major identity providers issue some of these incorrect tokens. Both options are disabled by default.

Changes to the Claims interface

Complete Restructuring

Previously, the claims interface was satisfied with an implementation of a Valid() error function. This had several issues:

  • The different claim types (struct claims, map claims, etc.) then contained similar (but not 100 % identical) code of how this validation was done. This lead to a lot of (almost) duplicate code and was hard to maintain
  • It was not really semantically close to what a "claim" (or a set of claims) really is; which is a list of defined key/value pairs with a certain semantic meaning.

Since all the validation functionality is now extracted into the validator, all VerifyXXX and Valid functions have been removed from the Claims interface. Instead, the interface now represents a list of getters to retrieve values with a specific meaning. This allows us to completely decouple the validation logic with the underlying storage representation of the claim, which could be a struct, a map or even something stored in a database.

type Claims interface {
	GetExpirationTime() (*NumericDate, error)
	GetIssuedAt() (*NumericDate, error)
	GetNotBefore() (*NumericDate, error)
	GetIssuer() (string, error)
	GetSubject() (string, error)
	GetAudience() (ClaimStrings, error)
}
Supported Claim Types and Removal of StandardClaims

The two standard claim types supported by this library, MapClaims and RegisteredClaims both implement the necessary functions of this interface. The old StandardClaims struct, which has already been deprecated in v4 is now removed.

Users using custom claims, in most cases, will not experience any changes in the behavior as long as they embedded RegisteredClaims. If they created a new claim type from scratch, they now need to implemented the proper getter functions.

Migrating Application Specific Logic of the old Valid

Previously, users could override the Valid method in a custom claim, for example to extend the validation with application-specific claims. However, this was always very dangerous, since once could easily disable the standard validation and signature checking.

In order to avoid that, while still supporting the use-case, a new ClaimsValidator interface has been introduced. This interface consists of the Validate() error function. If the validator sees, that a Claims struct implements this interface, the errors returned to the Validate function will be appended to the regular standard validation. It is not possible to disable the standard validation anymore (even only by accident).

Usage examples can be found in example_test.go, to build claims structs like the following.

// MyCustomClaims includes all registered claims, plus Foo.
type MyCustomClaims struct {
	Foo string `json:"foo"`
	jwt.RegisteredClaims
}

// Validate can be used to execute additional application-specific claims
// validation.
func (m MyCustomClaims) Validate() error {
	if m.Foo != "bar" {
		return errors.New("must be foobar")
	}

	return nil
}

Changes to the Token and Parser struct

The previously global functions DecodeSegment and EncodeSegment were moved to the Parser and Token struct respectively. This will allow us in the future to configure the behavior of these two based on options supplied on the parser or the token (creation). This also removes two previously global variables and moves them to parser options WithStrictDecoding and WithPaddingAllowed.

In order to do that, we had to adjust the way signing methods work. Previously they were given a base64 encoded signature in Verify and were expected to return a base64 encoded version of the signature in Sign, both as a string. However, this made it necessary to have DecodeSegment and EncodeSegment global and was a less than perfect design because we were repeating encoding/decoding steps for all signing methods. Now, Sign and Verify operate on a decoded signature as a []byte, which feels more natural for a cryptographic operation anyway. Lastly, Parse and SignedString take care of the final encoding/decoding part.

In addition to that, we also changed the Signature field on Token from a string to []byte and this is also now populated with the decoded form. This is also more consistent, because the other parts of the JWT, mainly Header and Claims were already stored in decoded form in Token. Only the signature was stored in base64 encoded form, which was redundant with the information in the Raw field, which contains the complete token as base64.

type Token struct {
	Raw       string                 // Raw contains the raw token
	Method    SigningMethod          // Method is the signing method used or to be used
	Header    map[string]interface{} // Header is the first segment of the token in decoded form
	Claims    Claims                 // Claims is the second segment of the token in decoded form
	Signature []byte                 // Signature is the third segment of the token in decoded form
	Valid     bool                   // Valid specifies if the token is valid
}

Most (if not all) of these changes should not impact the normal usage of this library. Only users directly accessing the Signature field as well as developers of custom signing methods should be affected.

What's Changed

New Contributors

Full Changelog: golang-jwt/jwt@v4.5.0...v5.0.0


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

To execute skipped test pipelines write comment /ok-to-test.


Documentation

Find out how to configure dependency updates in MintMaker documentation or see all available configuration options in Renovate documentation.

@red-hat-konflux

Copy link
Copy Markdown
Contributor Author

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: go.sum
Command failed: mod upgrade --mod-name=github.com/golang-jwt/jwt/v4 -t=5
could not load package: err: exit status 1: stderr: go: inconsistent vendoring in /tmp/renovate/repos/github/konflux-ci/integration-service:
	github.com/golang-jwt/jwt/v5@v5.3.1: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt

	To ignore the vendor directory, use -mod=readonly or -mod=mod.
	To sync the vendor directory, run:
		go mod vendor


@snyk-io

snyk-io Bot commented Feb 25, 2026

Copy link
Copy Markdown

Snyk checks have passed. No issues have been found so far.

Status Scan Engine Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues
Licenses 0 0 0 0 0 issues
Code Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@red-hat-konflux red-hat-konflux Bot force-pushed the konflux/mintmaker/main/github.com-golang-jwt-jwt-v4-5.x branch from 073b47a to deb8473 Compare February 26, 2026 06:05
@red-hat-konflux red-hat-konflux Bot force-pushed the konflux/mintmaker/main/github.com-golang-jwt-jwt-v4-5.x branch 2 times, most recently from bde8291 to 7e9efa4 Compare March 8, 2026 06:46
@red-hat-konflux red-hat-konflux Bot changed the title chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 - autoclosed Mar 25, 2026
@red-hat-konflux red-hat-konflux Bot closed this Mar 25, 2026
@red-hat-konflux red-hat-konflux Bot deleted the konflux/mintmaker/main/github.com-golang-jwt-jwt-v4-5.x branch March 25, 2026 14:24
@red-hat-konflux red-hat-konflux Bot changed the title chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 - autoclosed chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 Mar 25, 2026
@red-hat-konflux red-hat-konflux Bot reopened this Mar 25, 2026
@red-hat-konflux red-hat-konflux Bot force-pushed the konflux/mintmaker/main/github.com-golang-jwt-jwt-v4-5.x branch 3 times, most recently from 8e4deb1 to 55055a7 Compare March 26, 2026 09:59
@red-hat-konflux red-hat-konflux Bot force-pushed the konflux/mintmaker/main/github.com-golang-jwt-jwt-v4-5.x branch from 55055a7 to 87e3791 Compare April 2, 2026 23:37
@red-hat-konflux red-hat-konflux Bot changed the title chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 - autoclosed Apr 9, 2026
@red-hat-konflux red-hat-konflux Bot closed this Apr 9, 2026
@red-hat-konflux red-hat-konflux Bot changed the title chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 - autoclosed chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 Apr 9, 2026
@red-hat-konflux red-hat-konflux Bot reopened this Apr 9, 2026
@red-hat-konflux red-hat-konflux Bot force-pushed the konflux/mintmaker/main/github.com-golang-jwt-jwt-v4-5.x branch 2 times, most recently from 87e3791 to c2e734f Compare April 9, 2026 06:39
@red-hat-konflux red-hat-konflux Bot changed the title chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 - autoclosed May 23, 2026
@red-hat-konflux red-hat-konflux Bot closed this May 23, 2026
@red-hat-konflux red-hat-konflux Bot changed the title chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 - autoclosed chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 May 24, 2026
@red-hat-konflux red-hat-konflux Bot reopened this May 24, 2026
@red-hat-konflux red-hat-konflux Bot force-pushed the konflux/mintmaker/main/github.com-golang-jwt-jwt-v4-5.x branch 2 times, most recently from 3283d00 to a6ab83d Compare May 24, 2026 06:43
@red-hat-konflux red-hat-konflux Bot changed the title chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 - autoclosed May 28, 2026
@red-hat-konflux red-hat-konflux Bot closed this May 28, 2026
@red-hat-konflux red-hat-konflux Bot changed the title chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 - autoclosed chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 May 28, 2026
@red-hat-konflux red-hat-konflux Bot reopened this May 28, 2026
@red-hat-konflux red-hat-konflux Bot force-pushed the konflux/mintmaker/main/github.com-golang-jwt-jwt-v4-5.x branch 2 times, most recently from a6ab83d to 79ea319 Compare May 28, 2026 18:54
@red-hat-konflux red-hat-konflux Bot changed the title chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 - autoclosed Jun 5, 2026
@red-hat-konflux red-hat-konflux Bot closed this Jun 5, 2026
@red-hat-konflux red-hat-konflux Bot changed the title chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 - autoclosed chore(deps): update module github.com/golang-jwt/jwt/v4 to v5 Jun 5, 2026
@red-hat-konflux red-hat-konflux Bot reopened this Jun 5, 2026
@red-hat-konflux red-hat-konflux Bot force-pushed the konflux/mintmaker/main/github.com-golang-jwt-jwt-v4-5.x branch from a4c2da5 to 79ea319 Compare June 5, 2026 18:52
@fullsend-ai-review

fullsend-ai-review Bot commented Jun 5, 2026

Copy link
Copy Markdown

Review

Findings

Critical

  • [API contract violation] go.mod:113 — This PR changes go.mod to require github.com/golang-jwt/jwt/v5 but the only consumer of this dependency is the vendored github.com/bradleyfalzon/ghinstallation/v2 library, which explicitly imports github.com/golang-jwt/jwt/v4 (see vendor/github.com/bradleyfalzon/ghinstallation/v2/sign.go:6 and appsTransport.go:12). In Go modules, /v4 and /v5 are distinct module paths. Simply swapping the go.mod entry from v4 to v5 will not satisfy ghinstallation/v2's v4 import — the build will fail because jwt/v4 is no longer declared as a dependency. Additionally, go.sum, vendor/modules.txt, and the vendored jwt/v4 source directory are not updated in this diff, meaning go mod tidy / go mod vendor was not run. This PR as-is will break compilation.
    Remediation: The jwt/v4 to jwt/v5 migration cannot be done by changing go.mod alone. Either (1) upgrade ghinstallation/v2 to a version that depends on jwt/v5 and then run go mod tidy && go mod vendor, or (2) if no such version exists, keep jwt/v4 until the upstream library migrates. Do not manually swap the module path in go.mod without ensuring all transitive consumers are compatible.

Labels: Renovate bot dependency update PR should carry the dependencies label.

Previous run

Review

Findings

Critical

  • [build breakage / module inconsistency] go.mod:109 — The PR replaces the go.mod requirement for github.com/golang-jwt/jwt/v4 v4.5.2 with github.com/golang-jwt/jwt/v5 v5.3.1. In Go modules, v4 and v5 are distinct module paths. The vendored dependency ghinstallation/v2 hard-codes imports of jwt/v4 (sign.go:6, appsTransport.go:12). Removing the v4 require breaks this transitive dependency. Additionally, go.sum contains only v4 checksums, vendor/modules.txt references only v4, and no vendor/github.com/golang-jwt/jwt/v5/ directory exists. The PR changes only go.mod with none of the required corresponding updates to go.sum or vendor/. This will fail go mod verify, go mod vendor, and the build.
    Remediation: Do not merge as-is. Either: (a) upgrade ghinstallation/v2 to a version that depends on jwt/v5, then run go mod tidy && go mod vendor and include all resulting changes; or (b) keep jwt/v4 until upstream ghinstallation migrates. All of go.mod, go.sum, and vendor/ must be updated consistently.
Previous run (2)

Review

Findings

Critical

  • [logic-error] go.mod:109 — The PR changes the go.mod entry from github.com/golang-jwt/jwt/v4 v4.5.2 to github.com/golang-jwt/jwt/v5 v5.3.1, but this is an incomplete and inconsistent change that will break the build. In Go modules, v4 and v5 are entirely different module paths. The vendored dependency github.com/bradleyfalzon/ghinstallation/v2 explicitly imports github.com/golang-jwt/jwt/v4 (in vendor/github.com/bradleyfalzon/ghinstallation/v2/sign.go and appsTransport.go). Since jwt/v4 is an indirect dependency pulled in by ghinstallation/v2, it cannot be replaced with jwt/v5 unless ghinstallation/v2 itself is upgraded to a version that depends on jwt/v5. Furthermore: (1) go.sum still only contains checksums for jwt/v4, not jwt/v5; (2) vendor/modules.txt still references jwt/v4; (3) the vendor/ directory contains jwt/v4 source files, not jwt/v5. The PR only modifies go.mod and none of the other files that must change in concert, so go mod verify, go mod vendor, and the build itself will all fail.
    Remediation: Do not merge this PR as-is. The correct approach is either: (a) upgrade github.com/bradleyfalzon/ghinstallation/v2 to a version that itself depends on jwt/v5, then run go mod tidy && go mod vendor to update all generated files consistently; or (b) if no such version of ghinstallation/v2 exists, reject this major-version bump entirely since the transitive consumer still requires v4.
Previous run (3)

Review

Findings

Critical

  • [api-contract] go.mod:109 — The PR changes the indirect dependency from github.com/golang-jwt/jwt/v4 to github.com/golang-jwt/jwt/v5, but the direct consumer github.com/bradleyfalzon/ghinstallation/v2 explicitly imports github.com/golang-jwt/jwt/v4 (in vendor/github.com/bradleyfalzon/ghinstallation/v2/appsTransport.go and sign.go). In Go, v4 and v5 are entirely different module paths. Replacing the v4 module entry in go.mod with v5 does not satisfy the v4 import — the build will fail because the v4 module is no longer declared as a dependency, yet ghinstallation still requires it.
    Remediation: Do not remove the jwt/v4 indirect dependency from go.mod unless ghinstallation/v2 is also upgraded to a version that imports jwt/v5. Check whether a newer version of github.com/bradleyfalzon/ghinstallation/v2 exists that depends on jwt/v5; if so, upgrade both together. If not, this change must be reverted.

High

  • [pattern-violation] go.mod:109 — The PR modifies only go.mod but does not update go.sum, vendor/modules.txt, or the vendor directory. go.sum still contains checksums for jwt/v4 only (no v5 entries). vendor/modules.txt still lists jwt/v4 v4.5.2. The vendored source at vendor/github.com/golang-jwt/jwt/v4/ is unchanged. Even if the module path swap were valid, the vendor directory is inconsistent with go.mod, and go mod verify / go mod vendor would fail.
    Remediation: After resolving the v4-vs-v5 consumer compatibility issue, run go mod tidy && go mod vendor and commit the resulting changes to go.sum, vendor/modules.txt, and the vendor directory.

@fullsend-ai-review fullsend-ai-review Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the review comment for full details.

Comment thread go.mod
github.com/go-task/slim-sprig/v3 v3.0.0 // indirect
github.com/go-viper/mapstructure/v2 v2.4.0 // indirect
github.com/golang-jwt/jwt/v4 v4.5.2 // indirect
github.com/golang-jwt/jwt/v5 v5.3.1 // indirect

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[critical] api-contract

The PR changes the indirect dependency from github.com/golang-jwt/jwt/v4 to github.com/golang-jwt/jwt/v5, but the direct consumer github.com/bradleyfalzon/ghinstallation/v2 explicitly imports github.com/golang-jwt/jwt/v4. In Go, v4 and v5 are entirely different module paths. Replacing the v4 module entry with v5 does not satisfy the v4 import — the build will fail.

Suggested fix: Do not remove the jwt/v4 indirect dependency unless ghinstallation/v2 is upgraded to a version that imports jwt/v5. Check whether a newer ghinstallation/v2 exists that depends on jwt/v5; if so, upgrade both together. If not, revert this change.

Comment thread go.mod
github.com/go-task/slim-sprig/v3 v3.0.0 // indirect
github.com/go-viper/mapstructure/v2 v2.4.0 // indirect
github.com/golang-jwt/jwt/v4 v4.5.2 // indirect
github.com/golang-jwt/jwt/v5 v5.3.1 // indirect

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[high] pattern-violation

The PR modifies only go.mod but does not update go.sum, vendor/modules.txt, or the vendor directory. go.sum still contains checksums for jwt/v4 only. vendor/modules.txt still lists jwt/v4 v4.5.2. The vendored source is unchanged. The vendor directory is inconsistent with go.mod.

Suggested fix: After resolving the v4-vs-v5 consumer compatibility issue, run 'go mod tidy && go mod vendor' and commit the resulting changes to go.sum, vendor/modules.txt, and the vendor directory.

@fullsend-ai-retro

fullsend-ai-retro Bot commented Jun 20, 2026

Copy link
Copy Markdown

🤖 Finished Retro · ✅ Success · Started 12:00 PM UTC · Completed 12:08 PM UTC
Commit: 218f229 · View workflow run →

@fullsend-ai-retro

Copy link
Copy Markdown

Retro: PR #1475 — Renovate jwt/v4→v5 dependency bump (autoclosed)

What happened: Renovate bot opened a PR to bump golang-jwt/jwt from v4 to v5. This was fundamentally broken — in Go modules, v4 and v5 are different module paths, and the consumer (ghinstallation/v2) still imports v4. The PR cycled through ~10 autoclose/reopen/rebase cycles over 4 months before final closure on 2026-06-20.

Review quality: The review agent performed well, correctly identifying both the critical module path incompatibility and the missing vendor directory updates. Both findings were accurate and actionable.

Waste identified:

  1. The review agent ran on a PR where CI (Check sources, Go linters) was already failing — the review findings were correct but redundant with build failures.
  2. The retro agent ran twice: the first run (#27011955801) failed with a 403 token permissions error on the post-script. The second run (this one) was triggered by the final autoclose.
  3. A retro on a bot-authored dependency PR with no code agent involvement and a single (correct) review has limited value.

All improvement opportunities are already covered by existing open issues:

  • Skip/lighten review for bot PRs: #1371, #1358, #1355
  • Skip retro for autoclosed bot PRs: #2461
  • Deduplicate retro runs on same PR: #2401
  • Retro token permissions (403 on post-script): #2402
  • Review agent CLOSE verdict for broken bot PRs: #1980

No new proposals filed — all identified improvements have existing tracking issues.

@fullsend-ai-review

fullsend-ai-review Bot commented Jun 20, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 2:39 PM UTC · Completed 2:46 PM UTC
Commit: 218f229 · View workflow run →

@fullsend-ai-review fullsend-ai-review Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the review comment for full details.

Comment thread go.mod
github.com/go-task/slim-sprig/v3 v3.0.0 // indirect
github.com/go-viper/mapstructure/v2 v2.4.0 // indirect
github.com/golang-jwt/jwt/v4 v4.5.2 // indirect
github.com/golang-jwt/jwt/v5 v5.3.1 // indirect

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[critical] logic-error

The PR changes the go.mod entry from github.com/golang-jwt/jwt/v4 v4.5.2 to github.com/golang-jwt/jwt/v5 v5.3.1, but this is an incomplete and inconsistent change that will break the build. In Go modules, v4 and v5 are entirely different module paths. The vendored dependency github.com/bradleyfalzon/ghinstallation/v2 explicitly imports github.com/golang-jwt/jwt/v4 (in vendor/github.com/bradleyfalzon/ghinstallation/v2/sign.go and appsTransport.go). Since jwt/v4 is an indirect dependency pulled in by ghinstallation/v2, it cannot be replaced with jwt/v5 unless ghinstallation/v2 itself is upgraded to a version that depends on jwt/v5. Furthermore: (1) go.sum still only contains checksums for jwt/v4, not jwt/v5; (2) vendor/modules.txt still references jwt/v4; (3) the vendor/ directory contains jwt/v4 source files, not jwt/v5. The PR only modifies go.mod and none of the other files that must change in concert, so go mod verify, go mod vendor, and the build itself will all fail.

Suggested fix: Do not merge this PR as-is. The correct approach is either: (a) upgrade github.com/bradleyfalzon/ghinstallation/v2 to a version that itself depends on jwt/v5, then run go mod tidy && go mod vendor to update all generated files consistently; or (b) if no such version of ghinstallation/v2 exists, reject this major-version bump entirely since the transitive consumer still requires v4.

@fullsend-ai-retro

fullsend-ai-retro Bot commented Jun 21, 2026

Copy link
Copy Markdown

🤖 Finished Retro · ✅ Success · Started 2:45 PM UTC · Completed 2:52 PM UTC
Commit: 218f229 · View workflow run →

@fullsend-ai-retro

Copy link
Copy Markdown

Retro: PR #1475 (golang-jwt v4→v5 dependency bump)

This is the 3rd retro run on this PR. The previous retro (2026-06-20) already concluded that all identified improvements are tracked by existing issues. This retro confirms that assessment — no new proposals are warranted.

Timeline

  • 2026-02-25: Renovate bot opened PR with a single go.mod change bumping golang-jwt/jwt from v4 to v5. CI immediately failed (3 checks) because v4 and v5 are different Go module paths and transitive dependencies still require v4.
  • 2026-04-12, 2026-04-26: Human triggered /retest twice; CI continued to fail.
  • 2026-06-05: Review agent correctly identified the module path incompatibility and missing vendor updates (CHANGES_REQUESTED).
  • 2026-06-20: Review agent ran again on unchanged content, posting duplicate findings. First retro ran (failed with 403), second retro completed successfully.
  • 2026-06-21: PR autoclosed. Another review dispatch triggered on the close event. This (3rd) retro dispatched.

Waste observed

  • Redundant reviews: The review agent posted the same findings twice (Jun 5 and Jun 20) on unchanged content.
  • Review on closed PR: A review was dispatched when the PR was autoclosed.
  • Triple retro: This is the 3rd retro on the same PR, finding the same conclusions each time.
  • Review vs CI overlap: The review findings, while correct, were redundant with CI failures that had been visible since day one.

All improvements already tracked

Area Existing Issues
Skip review when CI fails #369, #1424
Skip/lighten review for bot PRs #1371, #1358, #1355
Skip review when PR is closed #1870, #1439
Deduplicate review findings #1013, #1500
CLOSE verdict for broken bot PRs #1980
Skip retro for autoclosed bot PRs #2461
Deduplicate retro runs #2401
Skip retro for bot PRs (review-only) #1630

No new proposals filed — all improvements are already tracked upstream.

@fullsend-ai-review

fullsend-ai-review Bot commented Jun 21, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 6:44 PM UTC · Completed 6:50 PM UTC
Commit: 218f229 · View workflow run →

@fullsend-ai-review fullsend-ai-review Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the review comment for full details.

Comment thread go.mod
github.com/go-task/slim-sprig/v3 v3.0.0 // indirect
github.com/go-viper/mapstructure/v2 v2.4.0 // indirect
github.com/golang-jwt/jwt/v4 v4.5.2 // indirect
github.com/golang-jwt/jwt/v5 v5.3.1 // indirect

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[critical] build breakage / module inconsistency

The PR replaces the go.mod requirement for github.com/golang-jwt/jwt/v4 v4.5.2 with github.com/golang-jwt/jwt/v5 v5.3.1. In Go modules, v4 and v5 are distinct module paths. The vendored dependency ghinstallation/v2 hard-codes imports of jwt/v4 (sign.go:6, appsTransport.go:12). Removing the v4 require breaks this transitive dependency. Additionally, go.sum contains only v4 checksums, vendor/modules.txt references only v4, and no vendor/github.com/golang-jwt/jwt/v5/ directory exists. The PR changes only go.mod with none of the required corresponding updates to go.sum or vendor/. This will fail go mod verify, go mod vendor, and the build.

Suggested fix: Do not merge as-is. Either: (a) upgrade ghinstallation/v2 to a version that depends on jwt/v5, then run go mod tidy && go mod vendor and include all resulting changes; or (b) keep jwt/v4 until upstream ghinstallation migrates. All of go.mod, go.sum, and vendor/ must be updated consistently.

Signed-off-by: red-hat-konflux <126015336+red-hat-konflux[bot]@users.noreply.github.com>
@fullsend-ai-review

fullsend-ai-review Bot commented Jun 25, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 10:30 PM UTC · Completed 10:37 PM UTC
Commit: ec21706 · View workflow run →

@fullsend-ai-review fullsend-ai-review Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the review comment for full details.

Comment thread go.mod
github.com/go-task/slim-sprig/v3 v3.0.0 // indirect
github.com/go-viper/mapstructure/v2 v2.4.0 // indirect
github.com/golang-jwt/jwt/v4 v4.5.2 // indirect
github.com/golang-jwt/jwt/v5 v5.3.1 // indirect

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[critical] API contract violation

This PR changes go.mod to require github.com/golang-jwt/jwt/v5 but the only consumer of this dependency is the vendored github.com/bradleyfalzon/ghinstallation/v2 library, which explicitly imports github.com/golang-jwt/jwt/v4 (see vendor/github.com/bradleyfalzon/ghinstallation/v2/sign.go:6 and appsTransport.go:12). In Go modules, /v4 and /v5 are distinct module paths. Simply swapping the go.mod entry from v4 to v5 will not satisfy ghinstallation/v2 v4 import -- the build will fail because jwt/v4 is no longer declared as a dependency. Additionally, go.sum, vendor/modules.txt, and the vendored jwt/v4 source directory are not updated in this diff, meaning go mod tidy / go mod vendor was not run. This PR as-is will break compilation.

Suggested fix: The jwt/v4 to jwt/v5 migration cannot be done by changing go.mod alone. Either (1) upgrade ghinstallation/v2 to a version that depends on jwt/v5 and then run go mod tidy && go mod vendor, or (2) if no such version exists, keep jwt/v4 until the upstream library migrates. Do not manually swap the module path in go.mod without ensuring all transitive consumers are compatible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file size: XS

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant