-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
add end-to-end C# update runner #10521
Conversation
e9f9d69
to
0c71f53
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tahnks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, left a few extra questions for my learning and better understanding
0c71f53
to
5c44007
Compare
5c44007
to
e97d96d
Compare
Is this supposed to work when central package management is enabled? I’m seeing the version failing to be located in that scenario. |
FYI, this breaks ability to build |
Add an option for the NuGet updater to handle the entire update process, from
git clone
all the way throughmark_as_processed
.This is necessary because the concept of a dependency according to MSBuild/NuGet is nothing like the concept of a dependency for
dependabot-core
and it would require a huge rewrite of a bunch of the common code, which really means a rewrite of all 20+ updaters, so this is the best way forwards. The short version for why NuGet is so different: MSBuild allows arbitrary directory crawling and each dependency found could be top-level or transitive and each one could have different updatability semantics based on the project's TFM and/orNuGet.Config
. Because of all of this, the NuGet updater needs to check every single dependency for upgradability; we can't do one big update check.The new behavior has been placed behind an experimental flag
nuget_native_updater
. To enable this, thebin/run
script was renamed tobin/run-original
(only in this image) and a newbin/run
checks the experiment flag in the job file and does the appropriate thing. To accomplish this, the Linux commandjq
was added to the image to query thejob.json
file for the flag. Powershell was also added as there's a newmain.ps1
that serves as the entrypoint. This was placed in a Powershell script because it makes it easy to test the clone and SDK installation on both Linux and Windows.The new
RunWorker
class is a simple wrapper aroundDiscoveryWorker
,AnalyzeWorker
, andUpdateWorker
and the only change to those three classes was to add an overload that takes and returns the object files directly, instead of requiring (de)serialization to/from disk. The old behavior remains unchanged. The actual body ofRunWorker
is fairly straightforward; the bulk of new lines in this PR is to support the object model required for the HTTP API calls (e.g.,create_pull_request
,mark_as_processed
, etc.)The only scenario covered by this code is very narrow and will fail in weird ways for the vast majority of update operations, but I wanted to get this work reviewed and merged so it can be slowly iterated on.
In this PR I'm primarily looking for feedback on the architecture/implementation of
main.ps1
andRunWorker.cs
; the rest is mainly plumbing code.