Skip to content
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.

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

ignore "empty" Go module updates #5123

Open
jmhodges opened this issue Jan 10, 2020 · 13 comments
Open

ignore "empty" Go module updates #5123

jmhodges opened this issue Jan 10, 2020 · 13 comments
Labels
manager:gomod Go Modules priority-4-low Low priority, unlikely to be done unless it becomes important to more people status:blocked Issue is blocked by another issue or external requirement type:feature Feature (new functionality)

Comments

@jmhodges
Copy link

jmhodges commented Jan 10, 2020

So, I'm getting lots of PRs like jmhodges/lekube#94, where the only changes are to the commit hash in the 3 files managed by the Go module system. There's no actual code changes in there beyond the version bump, because the Go module system (correctly) sees there were no relevant updates to the subpackages used by lekube.

It'd be cool if these "empty" PRs didn't happen. I get them every few days because those repos have new commits often. It's making pay less attention to all of my renovate PRs, because these "empty" PRs are far more common than the useful PRs.

@rarkins
Copy link
Collaborator

rarkins commented Jan 10, 2020

Do you have any ideas for how Renovate could "know" that? e.g. would an option "skip the PR completely if there's no change to vendor/" work?

@rarkins rarkins added manager:gomod Go Modules type:feature Feature (new functionality) needs-requirements labels Jan 10, 2020
@jmhodges
Copy link
Author

If the update only changes the files go.mod, go.sum, and vendor/modules.txt, then it's an empty one. So, "almost yes" to your question because vendor/modules.txt always changes when the commit sha is bumped even though no code does.

@rarkins
Copy link
Collaborator

rarkins commented Jan 10, 2020

Is the only way to determine this is after go mod vendor and check the results?

@jmhodges
Copy link
Author

Since I don’t know renovate’s codebase, I don’t think I can answer the question

@rarkins
Copy link
Collaborator

rarkins commented Jan 10, 2020

It's a Go question, not a Renovate question. If a Go dependency is not using modules (uses commits instead) and the commit is updated, can you tell if it's an "empty" change without running go mod vendor?

@jmhodges
Copy link
Author

Man, I’m sorry but I’m doing this on my free time. I have no idea how deep into the guts you need to go to not run the whole “go mod vendor” stuff. There’s clearly a world in which you can dig into that code to do less work but I have no idea what it entails

@rarkins rarkins added the priority-4-low Low priority, unlikely to be done unless it becomes important to more people label Jan 10, 2020
@rarkins rarkins added auto:reproduction A minimal reproduction is necessary to proceed status:requirements Full requirements are not yet known, so implementation should not be started and removed status:ready labels Jan 13, 2022
@github-actions
Copy link
Contributor

Hi there,

Help us by making a minimal reproduction repository.

Before we can start work on your issue we first need to know exactly what's causing the current behavior. A minimal reproduction helps us with this.

To get started, please read our guide on creating a minimal reproduction to understand what is needed.

We may close the issue if you (or someone else) have not provided a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.

Good luck,

The Renovate team

@thejan2009
Copy link

Hello there,
except for the files created by go mod vendor, I haven't found any other way to list changed dependency source code when upgrading a go.mod file.

Is there a way to gracefully abort and then ignore the upgrade with a PostUpgradeTask? That would allow us to detect and solve the above issue in a self-hosted deployment.

@rarkins
Copy link
Collaborator

rarkins commented Oct 27, 2022

Possibly a script which:

  • Uses git to check for any changes to the vendor dir
  • If no changes to the vendor dir, it uses git to reset the go.mod and go.sum values back to the base branch

Although manipulating git is usually not a good idea, this might end up working if it tricks Renovate into thinking there's no changes and to skip the branch.

Essential that someone can create a reproduction

@thejan2009
Copy link

thejan2009 commented Oct 27, 2022

See here: https://github.com/thejan2009/renovate-go-5123

catch.sh attempts to do what you described, but for some reason resetting the git folder does nothing and Renovate still finds the 3 files to update (go.mod, go.sum and vendor/modules.txt).

Edit: we want github.com/stretchr/testify@v1.8.0 to be upgraded only if there are changes

@rarkins
Copy link
Collaborator

rarkins commented Oct 27, 2022

I got a little further by modifying your renovate.json to include fileFilters: https://github.com/renovate-reproductions/5123/blob/main/renovate.json

And I confirmed manually that the comment correctly reset the values.

The problem is that today we match fileFilters against the output of git status.. which returns empty. I can think of a way to fix this hopefully

@rarkins
Copy link
Collaborator

rarkins commented Oct 27, 2022

Confirmed I could get the anticipated result with a bit of code mod:

 WARN: Detected empty commit - aborting git push (repository=renovate-reproductions/5123, branch=renovate/github.com-stretchr-testify-1.x)
       "commitRes": {
         "author": null,
         "branch": "",
         "commit": "",
         "root": false,
         "summary": {"changes": 0, "insertions": 0, "deletions": 0}
       }

But I need to think if there's a cleaner way

@rarkins
Copy link
Collaborator

rarkins commented Oct 27, 2022

Blocked by #18609

@rarkins rarkins added status:blocked Issue is blocked by another issue or external requirement and removed status:requirements Full requirements are not yet known, so implementation should not be started labels Oct 27, 2022
@rarkins rarkins added reproduction:provided and removed auto:reproduction A minimal reproduction is necessary to proceed labels May 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
manager:gomod Go Modules priority-4-low Low priority, unlikely to be done unless it becomes important to more people status:blocked Issue is blocked by another issue or external requirement type:feature Feature (new functionality)
Projects
None yet
Development

No branches or pull requests

3 participants