Skip to content

fix(deps): update go modules (major) #364

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.

Sign up for GitHub

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

Jump to bottom
Open
red-hat-konflux wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix(deps): update go modules (major) #364

red-hat-konflux wants to merge 1 commit into from
+99 −105

Conversation

@red-hat-konflux
Copy link
Contributor

@red-hat-konflux red-hat-konflux bot commented Jan 5, 2026 •
edited
Loading

This PR contains the following updates:

Package Change Age Confidence
github.com/cenkalti/backoff/v4 v4.3.0 -> v5.0.3 age confidence
github.com/golang-jwt/jwt/v4 v4.5.2 -> v5.3.0 age confidence
github.com/golang/snappy v0.0.4 -> v1.0.0 age confidence
github.com/hashicorp/hcl v1.0.0 -> v2.24.0 age confidence
github.com/jackc/pgx/v4 v4.18.3 -> v5.8.0 age confidence
github.com/redhatinsights/platform-go-middlewares v1.0.0 -> v2.0.0 age confidence
github.com/swaggo/files v1.0.1 -> v2.0.2 age confidence
github.com/zsais/go-gin-prometheus v0.1.0 -> v1.0.2 age confidence

Warning

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

Release Notes

cenkalti/backoff (github.com/cenkalti/backoff/v4)

v5.0.3

Compare Source

v5.0.2

Compare Source

v5.0.1

Compare Source

v5.0.0

Compare Source

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

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

golang/snappy (github.com/golang/snappy)

v1.0.0

Compare Source

Latest stable version, as of March 2025.

hashicorp/hcl (github.com/hashicorp/hcl)

v2.24.0

Compare Source

Enhancements
  • Add support for decoding block and attribute source ranges when using gohcl. (#​703)
  • hclsyntax: Detect and reject invalid nested splat result. (#​724)
Bugs Fixed
  • Correct handling of unknown objects in Index function. (#​763)

v2.23.0

Compare Source

Bugs Fixed
  • Preserve marks when traversing through unknown values. (#​699)
  • Retain marks through conditional and for expressions. (#​710)

v2.22.0

Compare Source

Enhancements
  • feat: return an ExprSyntaxError for invalid references that end in a dot (#​692)

v2.21.0

Compare Source

Enhancements
  • Introduce ParseTraversalPartial, which allows traversals that include the splat ([*]) index operator. (#​673)
  • ext/dynblock: Now accepts marked values in for_each, and will transfer those marks (as much as technically possible) to values in the generated blocks. (#​679)
Bugs Fixed
  • Expression evaluation will no longer panic if the splat operator is applied to an unknown value that has cty marks. (#​678)

v2.20.1

Compare Source

Bugs Fixed
  • Return ExprSyntaxError when an invalid namespaced function is encountered during parsing (#​668)
Internal
  • Standardize on only two value dumping/diffing libraries (#​669)

v2.20.0

Compare Source

Enhancements
  • Support for namespaced functions (#​639)
Bugs Fixed
  • ext/dynblock: if iterator is invalid return this error instead of consequential errors (#​656)

v2.19.1

Compare Source

What's Changed

Full Changelog: hashicorp/hcl@v2.19.0...v2.19.1

v2.19.0

Compare Source

Enhancements
  • ext/dynblock: dynblock.Expand now supports an optional hook for calling applications to check and potentially veto (by returning error diagnostics) particular for_each values. The behavior is unchanged for callers that don't set the new option. (#​634)
Bugs Fixed
  • hclsyntax: Further fixes for treatment of "marked" values in the conditional expression, and better tracking of refined values into the conditional expression results, building on the fixes from v2.18.1. (#​633)

v2.18.1

Compare Source

Bugs Fixed
  • hclsyntax: Conditional expressions will no longer panic when one or both of their results are "marked", as is the case for situations like how HashiCorp Terraform tracks its concept of "sensitive values". (#​630)

v2.18.0

Compare Source

Enhancements

  • HCL now uses the tables from Unicode 15 when performing string normalization and character segmentation. HCL was previously using the Unicode 13 tables.

    For calling applications where consistent Unicode support is important, consider also upgrading to Go 1.21 at the same time as adopting HCL v2.18.0 so that the standard library unicode tables (used for case folding, etc) will also be from Unicode 15.

v2.17.1

Compare Source

Enhancements
  • hclsyntax: When evaluating string templates that have a long known constant prefix, HCL will truncate the known prefix to avoid creating excessively-large refinements. String prefix refinements are intended primarily for relatively-short fixed prefixes, such as https:// at the start of a URL known to use that scheme. (#​617)
  • ext/tryfunc: The "try" and "can" functions now handle unknown values slightly more precisely, and so can return known values in more situations when given expressions referring to unknown symbols. (#​622)
Bugs Fixed
  • ext/typeexpr: Will no longer try to refine unknown values of unknown type when dealing with a user-specified type constraint containing the any keyword, avoiding an incorrect panic at runtime. (#​625)
  • ext/typeexpr: Now correctly handles attempts to declare the same object type attribute multiple times by returning an error. Previously this could potentially panic by creating an incoherent internal state. (#​624)

v2.17.0

Compare Source

Enhancements

  • HCL now uses a newer version of the upstream cty library which has improved treatment of unknown values: it can now track additional optional information that reduces the range of an unknown value, which allows some operations against unknown values to return known or partially-known results. (#​590)

    Note: This change effectively passes on cty's notion of backward compatibility whereby unknown values can become "more known" in later releases. In particular, if your caller is using cty.Value.RawEquals in its tests against the results of operations with unknown values then you may see those tests begin failing after upgrading, due to the values now being more "refined".

    If so, you should review the refinements with consideration to the cty refinements docs and update your expected results to match only if the reported refinements seem correct for the given situation. The RawEquals method is intended only for making exact value comparisons in test cases, so main application code should not use it; use Equals instead for real logic, which will take refinements into account automatically.

v2.16.2

Compare Source

Bugs Fixed
  • ext/typeexpr: Verify type assumptions when applying default values, and ignore input values that do not match type assumptions. (#​594)

v2.16.1

Compare Source

Bugs Fixed
  • hclsyntax: Report correct Range.End for FunctionCall with incomplete argument (#​588)

v2.16.0

Compare Source

Enhancements

  • ext/typeexpr: Modify the Defaults functionality to implement additional flexibility. HCL will now upcast lists and sets into tuples, and maps into objects, when applying default values if the applied defaults cause the elements within a target collection to have differing types. Previously, this would have resulted in a panic, now HCL will return a modified overall type. (#​574)

    Users should return to the advice provided by v2.14.0, and apply the go-cty convert functionality after setting defaults on a given cty.Value, rather than before.

  • hclfmt: Avoid rewriting unchanged files. (#​576)

  • hclsyntax: Simplify the AST for certain string expressions. (#​584)

Bugs Fixed
  • hclwrite: Fix data race in formatSpaces. (#​511)

v2.15.0

Compare Source

Bugs Fixed
  • ext/typeexpr: Skip null objects when applying defaults. This prevents crashes when null objects are creating inside collections, and stops incomplete objects being created with only optional attributes set. (#​567)
  • ext/typeexpr: Ensure default values do not have optional metadata attached. This prevents crashes when default values are inserted into concrete go-cty values that have also been stripped of their optional metadata. (#​568)
Enhancements
  • ext/typeexpr: With the go-cty upstream depenendency updated to v1.12.0, the Defaults struct and associated functions can apply additional and more flexible 'unsafe' conversions (examples include tuples into collections such as lists and sets, and additional safety around null and dynamic values). (#​564)
  • ext/typeexpr: With the go-cty upstream depenendency updated to v1.12.0, users should now apply the go-cty convert functionality before setting defaults on a given cty.Value, rather than after, if they require a specific cty.Type. (#​564)

v2.14.1

Compare Source

Bugs Fixed
  • ext/typeexpr: Type convert defaults for optional object attributes when applying them. This prevents crashes in certain cases when the objects in question are part of a collection. (#​555)

v2.14.0

Compare Source

Enhancements
  • ext/typeexpr: Added support for optional object attributes to TypeConstraint. Attributes can be wrapped in the special optional(…) modifier, allowing the attribute to be omitted while still meeting the type constraint. For more information, cty's documentation on conversion between object types. (#​549)
  • ext/typeexpr: New function: TypeConstraintWithDefaults. In this mode, the optional(…) modifier accepts a second argument which can be used as the default value for omitted object attributes. The function returns both a cty.Type and associated Defaults, the latter of which has an Apply method to apply defaults to a given value. (#​549)

v2.13.0

Compare Source

Enhancements
  • hcl: hcl.Diagnostic now has an additional field Extra which is intended for carrying arbitrary supporting data ("extra information") related to the diagnostic message, intended to allow diagnostic renderers to optionally tailor the presentation of messages for particular situations. (#​539)
  • hclsyntax: When an error occurs during a function call, the returned diagnostics will include extra information (as described in the previous point) about which function was being called and, if the message is about an error returned by the function itself, that raw error value without any post-processing. (#​539)
Bugs Fixed
  • hclwrite: Fixed a potential data race for any situation where hclwrite.Format runs concurrently with itself. (#​534)

v2.12.0

Compare Source

Enhancements
  • hclsyntax: Evaluation of conditional expressions will now produce more precise error messages about inconsistencies between the types of the true and false result expressions, particularly in cases where both are of the same structural type kind but differ in their nested elements. (#​530)
  • hclsyntax: The lexer will no longer allocate a small object on the heap for each token. Instead, in that situation it will allocate only when needed to return a diagnostic message with source location information. (#​490)
  • hclwrite: New functions TokensForTuple, TokensForObject, and TokensForFunctionCall allow for more easily constructing the three constructs which are supported for static analysis and which HCL-based languages typically use in contexts where an expression is used only for its syntax, and not evaluated to produce a real value. For example, these new functions together are sufficient to construct all valid type constraint expressions from the Type Expressions Extension, which is the basis of variable type constraints in the Terraform language at the time of writing. (#​502)
  • json: New functions IsJSONExpression and IsJSONBody to determine if a given expression or body was created by the JSON syntax parser. In normal situations it's better not to worry about what syntax a particular expression/body originated in, but this can be useful in some trickier cases where an application needs to shim for backwards-compatibility or for static analysis that needs to have special handling of the JSON syntax's embedded expression/template conventions. (#​524)
Bugs Fixed
  • gohcl: Fix docs about supported types for blocks. (#​507)

v2.11.1

Compare Source

Bugs Fixed
  • hclsyntax: The type for an upgraded unknown value with a splat expression cannot be known (#​495)

v2.11.0

Compare Source

Enhancements
  • hclsyntax: Various error messages related to unexpectedly reaching end of file while parsing a delimited subtree will now return specialized messages describing the opening tokens as "unclosed", instead of returning a generic diagnostic that just happens to refer to the empty source range at the end of the file. This gives better feedback when error messages are being presented alongside a source code snippet, as is common in HCL-based applications, because it shows which innermost container the parser was working on when it encountered the error. (#​492)
Bugs Fixed
  • hclsyntax: Upgrading an unknown single value to a list using a splat expression must return unknown (#​493)

v2.10.1

Compare Source

  • dynblock: Decode unknown dynamic blocks in order to obtain any diagnostics even though the decoded value is not used (#​476)
  • hclsyntax: Calling functions is now more robust in the face of an incorrectly-implemented function which returns a function.ArgError whose argument index is out of range for the length of the arguments. Previously this would often lead to a panic, but now it'll return a less-precice error message instead. Functions that return out-of-bounds argument indices still ought to be fixed so that the resulting error diagnostics can be as precise as possible. (#​472)
  • hclsyntax: Ensure marks on unknown values are maintained when processing string templates. (#​478)
  • hcl: Improved error messages for various common error situtions in hcl.Index and hcl.GetAttr. These are part of the implementation of indexing and attribute lookup in the native syntax expression language too, so the new error messages will apply to problems using those operators. (#​474)

v2.10.0

Compare Source

Enhancements
  • dynblock,hcldec: Using dynblock in conjunction with hcldec can now decode blocks with unknown dynamic for_each arguments as entirely unknown values (#​461)
  • hclsyntax: Some syntax errors during parsing of the inside of ${ ... } template interpolation sequences will now produce an extra hint message about the need to escape as $${ when trying to include interpolation syntax for other languages like shell scripting, AWS IAM policies, etc. (#​462)

v2.9.1

Compare Source

Bugs Fixed
  • hclsyntax: Fix panic for marked index value. (#​451)

v2.9.0

Compare Source

Enhancements
  • HCL's native syntax and JSON scanners -- and thus all of the other parsing components that build on top of them -- are now using Unicode 13 rules for text segmentation when counting text characters for the purpose of reporting source location columns. Previously HCL was using Unicode 12. Unicode 13 still uses the same algorithm but includes some additions to the character tables the algorithm is defined in terms of, to properly categorize new characters defined in Unicode 13.

v2.8.2

Compare Source

Bugs Fixed
  • hclsyntax: Fix panic for marked collection splat. (#​436)
  • hclsyntax: Fix panic for marked template loops. (#​437)
  • hclsyntax: Fix for expression marked conditional. (#​438)
  • hclsyntax: Mark objects with keys that are sensitive. (#​440)

v2.8.1

Compare Source

Bugs Fixed
  • hclsyntax: Fix panic when expanding marked function arguments. (#​429)
  • hclsyntax: Error when attempting to use a marked value as an object key. (#​434)
  • hclsyntax: Error when attempting to use a marked value as an object key in expressions. (#​433)

v2.8.0

Compare Source

Enhancements
  • hclsyntax: Expression grouping parentheses will now be reflected by an explicit node in the AST, whereas before they were only considered during parsing. (#​426)
Bugs Fixed
  • hclwrite: The parser will now correctly include the ( and ) tokens when an expression is surrounded by parentheses. Previously it would incorrectly recognize those tokens as being extraneous tokens outside of the expression. (#​426)
  • hclwrite: The formatter will now remove (rather than insert) spaces between the ! (unary boolean "not") operator and its subsequent operand. (#​403)
  • hclsyntax: Unmark conditional values in expressions before checking their truthfulness (#​427)

v2.7.2

Compare Source

Bugs Fixed
  • gohcl: Fix panic when decoding into type containing value slices. (#​335)
  • hclsyntax: The unusual expression null[*] was previously always returning an unknown value, even though the rules for [*] normally call for it to return an empty tuple when applied to a null. As well as being a surprising result, it was particularly problematic because it violated the rule that a calling application may assume that an expression result will always be known unless the application itself introduces unknown values via the evaluation context. null[*] will now produce an empty tuple. (#​416)
  • hclsyntax: Fix panic when traversing a list, tuple, or map with cty "marks" (#​424)

v2.7.1

Compare Source

Bugs Fixed
  • hclwrite: Correctly handle blank quoted string block labels, instead of dropping them (#​422)

v2.7.0

Compare Source

Enhancements
  • json: There is a new function ParseWithStartPos, which allows overriding the starting position for parsing in case the given JSON bytes are a fragment of a larger document, such as might happen when decoding with encoding/json into a json.RawMessage. (#​389)
  • json: There is a new function ParseExpression, which allows parsing a JSON string directly in expression mode, whereas previously it was only possible to parse a JSON string in body mode. (#​381)
  • hclwrite: Block type now supports SetType and SetLabels, allowing surgical changes to the type and labels of an existing block without having to reconstruct the entire block. (#​340)
Bugs Fixed
  • hclsyntax: Fix confusing error message for bitwise OR operator (#​380)
  • hclsyntax: Several bug fixes for using HCL with values containing cty "marks" (#​404, #​406, #​407)

v2.6.0

Compare Source

Enhancements
  • hcldec: Add a new Spec, ValidateSpec, which allows custom validation of values at decode-time. (#​387)
Bugs Fixed
  • hclsyntax: Fix panic with combination of sequences and null arguments (#​386)
  • hclsyntax: Fix handling of unknown values and sequences (#​386)

v2.5.1

Compare Source

Bugs Fixed
  • hclwrite: handle legacy dot access of numeric indexes. (#​369)
  • hclwrite: Fix panic for dotted full splat (foo.*) (#​374)

v2.5.0

Compare Source

Enhancements
  • hclwrite: Generate multi-line objects and maps. (#​372)

v2.4.0

[Compar

Configuration

📅 Schedule: 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.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • 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
Contributor Author

red-hat-konflux bot commented Jan 5, 2026

⚠️ 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: local_setup/go.sum
Command failed: go get -t ./...
go: github.com/Shopify/[email protected]: parsing go.mod:
	module declares its path as: github.com/IBM/sarama
	        but was required as: github.com/Shopify/sarama

@jira-linking
Copy link

jira-linking bot commented Jan 5, 2026 •
edited
Loading

Commits missing Jira IDs:
0019807

@red-hat-konflux red-hat-konflux bot force-pushed the konflux/mintmaker/master/major-go-modules branch 10 times, most recently from e5014d9 to eb529fc Compare January 11, 2026 08:45
@red-hat-konflux
fix(deps): update go modules
0019807 
Signed-off-by: red-hat-konflux <126015336+red-hat-konflux[bot]@users.noreply.github.com>
@red-hat-konflux red-hat-konflux bot force-pushed the konflux/mintmaker/master/major-go-modules branch from eb529fc to 0019807 Compare January 11, 2026 12:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants