Alow grouping updates per solution

[Maggus85]

Is there an existing issue for this?

• [X] I have searched the existing issues

Feature description

I have a .net solution with structure

solution.sln

• Api.csproj
• Aplication.csproj

• Infrasctructure.csproj

  Each project have some public and private nuget dependencies, I would like to create two pr for this solution

• first - with public dependencies

• second - with private dependencies

  Currently with grouping option I'm only able to create those pr per project not per solution, so in effect I have

  • pr for Apiwith public dependencies
  • pr for Api with private dependendencies
  • pr for Aplication with public dependencies
  • pr for Aplication with private dependendencies
  • pr for Infrasctructure with public dependencies
  • pr for Infrasctructure with private dependendencies

  I'm using configuration

`version: 2 registries: farm-cloud: type: nuget-feed url: https://agrisolutionseu.pkgs.visualstudio.com/_packaging/FarmCloud/nuget/v3/index.json token: PAT:${{VSS_NUGET_ACCESSTOKEN}} nuget: type: nuget-feed url: https://api.nuget.org/v3/index.json schedule: interval: "daily" updates:

• package-ecosystem: "nuget" directory:
  • /src/API/AS.FarmCloud.Sensor.Storage/ open-pull-requests-limit: 20 registries:
  • farm-cloud
  • nuget groups: internal-libs: applies-to: version-updates patterns:
  • AS*`

[torbacz]

Guys, this is a critical bug for nuget updates. The SLN file is a whole application - if you update only packages in one project of SLN - the build will fail, as other project may required different versions. With current implementation it's almost impossible to use it with .NET applications!

[brettfo]

All .NET and NuGet tools are supposed to honor the NuGet.Config files in a repo, and because of that, there's not really a way to trigger an update job for just one feed, because the NuGet.Config would contain both.

You could simulate this behavior, however, by specifying multiple jobs in the dependabot.yml file and restricting the names of packages that are considered updateable. In the following example, assume that a private package feed contains packages with names like MyCompanyName.Utils and SomeOtherCompanyName.ThirdPartyComponent. You could specify two jobs like this:

version: 2
updates:
  # this matches the packages from the private feed
  - package-ecosystem: "nuget"
    directory: "/"
    schedule:
      interval: "weekly"
    allow:
      - dependency-name: "MyCompanyName.*"
      - dependency-name: "SomeOtherCompanyName.*"
  # this matches everything else, e.g., the public packages
  - package-ecosystem: "nuget"
    directory: "/"
    schedule:
      interval: "weekly"
    ignore:
      - dependency-name: "MyCompanyName.*"
      - dependency-name: "SomeOtherCompanyName.*"

The key difference being the allow and ignore elements.

[torbacz]

@brettfo Thanks for feedback, yet assuming I've got serveral .csproj files in directory (which is normal for .NET projects), it will create PR for each project?

[brettfo]

@torbacz There should only be 1 PR created. An update job is only given a directory as a starting point so the first thing we do is expand all possible files, so we grab every .csproj, .vbproj, and .fsproj, then we expand any .sln to multiple projects (same .csproj etc. filter) and finally we also allow dirs.proj to be expanded (that's similar to a .sln, just a way of listing several projects together.) Then we attempt to update dependencies on every project we found and that includes traversing <ProjectReference> elements, so it's entirely possible to start an update job in the /tests/SomeTest directory, see a /tests/SomeTest/SomeTest.csproj file, follow <ProjectReference Include="..\..\src\CommonUtils\CommonUtils.csproj" /> and ultimately make an edit to the file /src/CommonUtils/CommonUtils.csproj. Because MSBuild allows arbitrary directory crawling, we could end up anywhere.

[torbacz]

@brettfo The problem is, that it's not working that way.

Maybe it will be faster if I include config file :)

version: 2
registries:
  farm-cloud:
    type: nuget-feed
  nuget:
    type: nuget-feed
    url: https://api.nuget.org/v3/index.json

schedule:
  interval: "daily"

updates:
  - package-ecosystem: "nuget"
    directory: "/src/API/AS.FarmCloud.Sensor.Storage/"
    open-pull-requests-limit: 2
    registries:
      - farm-cloud
      - nuget
    allow:
      - dependency-name: "AS.*"
    groups:
      - others-s:
          applies-to: security-updates
          patterns:
            - "*"
      - others-v:
          applies-to: version-updates
          patterns:
            - "*"

With this configuration, PR per project is getting created - which causing CI build to fail. Both projects are part of the same SLN file.

[brettfo]

@torbacz Can you link the repo where you have this file? Specifically, what files are in the directory "/src/API/AS.FarmCloud.Sensor.Storage/"? Generally all changes are combined into a single PR, but that's obviously not happening here.

[torbacz]

@brettfo That's private repo, can't link that. But I'll create public github repository later this week.