Dependabot updates are failing due to missing .NET SDK #9249
Labels
Comments
|
cc: @abdulapopoola I've created this issue per your direction. I shared in in the previous thread because it was an emergent issue that on PRs that were effected by the previous issue with grouped updates. I'm not sure if its related or not, but it seemed like it could be relevant. |
|
Here is a link to the PR that ended up being (I believe incorrectly closed due to the error):
|
|
Same here, but for different SDK versions: PR that was closed due to this: dorssel/dotnet-ef-sqlite-timestamp#9 |
|
Seeing this now as well. I'm expecting a lot more to come in Sunday/Monday when dependabot runs on schedule 😕 Run log
https://github.com/xt0rted/dotnet-rimraf/network/updates/797839098 |
|
Checked for updates in one of my private repos and all 4 PRs were just closed with the same basic error as in my public repo.
Run log
|
|
Running into this as well across several SDK versions, including |
|
For the sake of tracking, I've created a repo with a minimal repro of the issue: |
|
Also hitting this - I'd opened #9245. |
|
Also hitting this, .Net SDK version 8.0.201. |
|
This is currently affecting every repo where I have a It only happens when a dependency needs to be updated and the |
|
Dependabot is pretty unreliable since a couple of weeks now for .NET, there is no regression tests ? I also see each fix take a long time to be available. To improve this experience, there are any possibility to have more control of which version we can use ? It would be nice if admin can set the target version of Dependabot with a 'stable' and a 'preview' rings. This may simplify the deployment and testing of a new version of Dependabot for detect regressions and include some fixes before the general availability of a version. If @abdulapopoola can help to prioritize this issue and the overall quality issue, this would be nice. Thanks. |
Merged
|
The first fix shipped; can you please confirm if this resolves the issue? |
|
@abdulapopoola This is working, thank you so much for the quick fix 🎉 |
|
Credit goes to @brettfo for the fix and @JamieMagee and @JoeRobich for the quick reviews! |
|
Closing as this is now confirmed to work; please reactivate if this still happens |
1 task
|
I manually triggered an update in two of my repos. One has a Update log
|
|
@xt0rted ; this would require something like #9286. On second thoughts, I think we can try installing multiple .net versions as a temp fix before we get to #9286? Thoughts @jakecoffman , @JamieMagee , @brettfo ? Would that work? |
|
I've created #9287 to track this scenario. |
|
This same behaviour is now happening for global.json with 8.0.203 (released 14 March), since #9282 bumped the DOTNET_SDK_VERSION to 8.0.202 the day before 8.0.203 was released. Is there no sustainable solution that could avoid this repeatedly being an issue with latest SDK version? |
|
That should have been resolved by #9374 - I've been using 8.0.203 in all my repos since it was released last month, and I've had no dependabot issues since that fix was deployed. |
|
Thanks @martincostello. I'm definitely still seeing it. See extract from a failed dependabot run from yesterday below. |
|
I'm still seeing it in some of my repositories, for requested SDK version: 6.0.0. The exception log looks exactly same as in @mjfpalmer 's comment above. Update 04/16: It happens always when an actual update to nuget package is going to be applied. Jobs with no updates pass without the exception. |
|
It happened also for my repo 5 hours ago |
|
tagging @brettfo in case he knows. |
1 similar comment
|
tagging @brettfo in case he knows. |
|
Question for @mjfpalmer @sirtyman @kicaj29 Is this happening in a public GitHub repo and can you share the details with me? We have a unit test that should cover this scenario here but we're obviously missing something. |
|
It is private repo but if you will tell me what would help you with fixing it I can share redacted files. |
|
@brettfo, mine is also private, but I've replicated the failure in a new public repo. See https://github.com/mjfpalmer/dependabot-test. |
|
I wonder if it's because |
|
Doesn't seem so @martincostello. I moved Interestingly, one of the 3 projects is now succeeding, but it succeeded in a run an hour before I moved global.json. See https://github.com/mjfpalmer/dependabot-test/network/updates. The success didn't report any failures, but it also didn't create an update PR, which it should have done. |
|
FYI I did notice when I reported #9495 that the job is green in the run logs, but the error is present if you read the logs i.e. it looks like it's working but nothing happens. |
|
@martincostello, I added you as a collaborator to https://github.com/mjfpalmer/dependabot-test. Does that give you access to |
|
Yep, I can see the errors now. Two where it's |
|
I could also reproduce the issue in my public repo: https://github.com/sirtyman/reproduce_dependabot_issue . The job failed with the same stacktrace as in our private repo (added @kicaj29 to this message). |
|
The first stable version was 6.0.100. Try changing that and see what happens. |
|
Changed it to 6.0.100. Still the same issue is appearing. |
|
Thanks everybody for the quick response, I've identified the issue and I'm currently looking at the best way to handle it. The short version is that when |
|
PR has been merged, it shouldn't be too long now until you should start to see changes coming through again. |
|
Working in https://github.com/mjfpalmer/dependabot-test, thank you @brettfo! |
|
Also, working in https://github.com/sirtyman/reproduce_dependabot_issue, thank you @brettfo ! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Unsure if its related, but I am getting a lot of exceptions regarding .NET SDK installation failures on the dependabot update logs, here's a snip:
I'm seeing this across a few different repositories for different packages.
Originally posted by @fuzzzerd in #8576 (comment)
The text was updated successfully, but these errors were encountered: