Gomod 1.21 integration test

[taylormadore]

Two integration tests added here:

• An additional branch of our gomod e2e test repo that uses minimum go version 1.21. We'll have one e2e test each for Go < 1.21 and Go == 1.21.
• A test that verifies that we process projects specifying minimum Go version < 1.21 with Go < 1.21.

After this has been reviewed+approved, I'll add similar tests for cachito.

Maintainers will complete the following section

• [x] Commit messages are descriptive enough
• [x] Code coverage from testing does not decrease and new code is covered
• [ ] ~Docs updated (if applicable)~
• [ ] ~Docs links in the code are still valid (if docs were updated)~

Note: if the contribution is external (not from an organization member), the CI pipeline will not run automatically. After verifying that the CI is safe to run:

• approve GitHub Actions workflows by clicking a button
• approve the Red Hat Trusted App Pipeline container build by commenting /ok-to-test (as is the standard for Pipelines as Code)

[taylormadore]

can we use branch within some already created repo in cachito-testing org? We tried to have less repos for cachi2

Sorry, I just noticed this comment :sweat_smile:

I had kept this in a separate repo because it was quite a specific test and I had created tags for the individual modules. I can move it though if you both want. Any suggestions for where?

[brunoapimentel]

can we use branch within some already created repo in cachito-testing org? We tried to have less repos for cachi2

Sorry, I just noticed this comment 😅

I had kept this in a separate repo because it was quite a specific test and I had created tags for the individual modules. I can move it though if you both want. Any suggestions for where?

Did we agree on having a different approach for Cachi2? The way I see the cachito-testing org today, it is split between some package manager based repos (like cachi2-yarn-berry) and scenario based repos (see npm-cachi2-* and most of the older tests). I don't mind either way, but I don't think we've been consistent. I also think splitting the tests in Cachito/Cachi2 is not ideal, as some of the tests are shared.

If the tests can be made in separate branches in a single repo per package manager (for both Cachito and Cachi2) without conflicts, I'd be fine with that approach going forward.

[ejegrova]

can we use branch within some already created repo in cachito-testing org? We tried to have less repos for cachi2

Sorry, I just noticed this comment 😅 I had kept this in a separate repo because it was quite a specific test and I had created tags for the individual modules. I can move it though if you both want. Any suggestions for where?

Did we agree on having a different approach for Cachi2? The way I see the cachito-testing org today, it is split between some package manager based repos (like cachi2-yarn-berry) and scenario based repos (see npm-cachi2-* and most of the older tests). I don't mind either way, but I don't think we've been consistent. I also think splitting the tests in Cachito/Cachi2 is not ideal, as some of the tests are shared.

If the tests can be made in separate branches in a single repo per package manager (for both Cachito and Cachi2) without conflicts, I'd be fine with that approach going forward.

There was an agreement in the original cachi2 design to use one repo with branches. As you can see it went sideways, but IMO we could keep one repo for package manager if possible. Scenario based repos are making unnecessary clutter.

Maybe use https://github.com/cachito-testing/cachi2-gomod for this case too? I set it up for workspaces because there was no other gomod tests related to cachi2.

[taylormadore]

• Rebased on main
• Moved and of the tests to repo https://github.com/cachito-testing/cachi2-gomod/tree/gomod-1.21-dirty-repo

we should already start preparing test to cover what is being discussed in https://github.com/containerbuildsystem/cachi2/issues/501

Let's do it as a follow-up. The idea I have in mind should be simple