Provide details for `update_not_possible`

[Piedone]

Is there an existing issue for this?

• [X] I have searched the existing issues

Feature description

When we at Orchard Core get update_not_possible, we are always confused why the update is not possible, as there's no indication of it in Dependabot's output. Please make Dependabot output error details, thus making the error actionable and something that we can thus fix.

We've encountered this with NuGet updates, but the issue might span all package ecosystems.

https://github.com/dependabot/dependabot-core/issues/5301 and https://github.com/dependabot/dependabot-core/issues/8903 are related but I think are about slightly different angles. Also, this is related to NuGet updates if that makes a difference.

E.g. this run failed for libphonenumber-csharp with the following output:

2024-10-04T10:48:16.5645537Z updater | 2024/10/04 10:48:16 INFO Updating libphonenumber-csharp from 8.13.46 to 8.13.47 2024-10-04T10:48:16.6126080Z proxy | 2024/10/04 10:48:16 [330] POST /update_jobs/895909503/record_update_job_error 2024-10-04T10:48:16.7107816Z proxy | 2024/10/04 10:48:16 [330] 204 /update_jobs/895909503/record_update_job_error 2024-10-04T10:48:16.7117902Z updater | 2024/10/04 10:48:16 INFO Handled error whilst updating libphonenumber-csharp: update_not_possible {:dependencies=>["libphonenumber-csharp"]}

This provides no details. At the end of the workflow output, we have "For more information see: https://github.com/OrchardCMS/OrchardCore/network/updates/895909503 (write access to the repository is required to view the log)" but that just brings us to this page:

This is despite dependabot.yml being there and configuring this update (what the Configure button actually points to too):

version: 2
updates:
  # Dependabot can handle at most 150 "manifests", so for NuGet, csprojs referencing packages (see docs:
  # https://docs.github.com/en/enterprise-cloud@latest/code-security/supply-chain-security/understanding-your-software-supply-chain/troubleshooting-the-dependency-graph#are-there-limits-which-affect-the-dependency-graph-data).
  # Thus, it would fail for the whole solution.
  # Grouping updates per directories or otherwise trying to have smaller batches is unnecessary, because due to
  # centralized package management, Dependabot will find all dependencies from any project. So, just processing the
  # OrchardCore project.
  - package-ecosystem: "nuget"
    directory: "/src/OrchardCore/OrchardCore"
    schedule:
      interval: "weekly"
    groups:
       all-dependencies:
          patterns:
            - "*"
    ignore:
      # We'll update GraphQL for v3 because it's breaking, see https://github.com/OrchardCMS/OrchardCore/issues/16826.
      - dependency-name: "GraphQL*"
      # See the corresponding comment in Directory.Packages.props.
      - dependency-name: "System.Drawing.Common"

Even before when this page recognized the configuration being present, it just linked back to the workflow output.

[fredericboyer]

This needs to increase in terms of visibility priority, we have roughly 28 .NET dependencies that fail to update with a similar message that is quite useless.

e.g.,

2024-10-24T18:19:45.2257740Z updater | 2024/10/24 18:19:45 INFO <job_906158683> Checking if Dapper 2.0.35 needs updating
2024-10-24T18:19:45.3275490Z   proxy | 2024/10/24 18:19:45 [368] GET [https://api.nuget.org:443/v3/registration5-gz-semver2/dapper/index.json](https://api.nuget.org/v3/registration5-gz-semver2/dapper/index.json)
2024-10-24T18:19:45.4090527Z   proxy | 2024/10/24 18:19:45 [368] 200 [https://api.nuget.org:443/v3/registration5-gz-semver2/dapper/index.json](https://api.nuget.org/v3/registration5-gz-semver2/dapper/index.json)
2024-10-24T18:19:45.5303231Z updater | 2024/10/24 18:19:45 INFO <job_906158683> Filtered out 20 pre-release versions
2024-10-24T18:19:45.6316097Z   proxy | 2024/10/24 18:19:45 [370] GET [https://api.nuget.org:443/v3-flatcontainer/dapper/2.0.35/dapper.nuspec](https://api.nuget.org/v3-flatcontainer/dapper/2.0.35/dapper.nuspec)
2024-10-24T18:19:45.6347312Z   proxy | 2024/10/24 18:19:45 [370] 200 [https://api.nuget.org:443/v3-flatcontainer/dapper/2.0.35/dapper.nuspec](https://api.nuget.org/v3-flatcontainer/dapper/2.0.35/dapper.nuspec)
2024-10-24T18:19:45.6422552Z updater | 2024/10/24 18:19:45 INFO <job_906158683> Latest version is 2.1.35
2024-10-24T18:19:45.6433987Z updater | 2024/10/24 18:19:45 INFO <job_906158683> Requirements to unlock all
2024-10-24T18:19:45.6435059Z 2024/10/24 18:19:45 INFO <job_906158683> Requirements update strategy 
2024-10-24T18:19:45.6435935Z updater | Finding updated dependencies for Dapper.
2024-10-24T18:19:45.7435937Z   proxy | 2024/10/24 18:19:45 [372] GET [https://api.nuget.org:443/v3-flatcontainer/dapper/2.1.35/dapper.nuspec](https://api.nuget.org/v3-flatcontainer/dapper/2.1.35/dapper.nuspec)
2024-10-24T18:19:45.7517383Z   proxy | 2024/10/24 18:19:45 [372] 200 [https://api.nuget.org:443/v3-flatcontainer/dapper/2.1.35/dapper.nuspec](https://api.nuget.org/v3-flatcontainer/dapper/2.1.35/dapper.nuspec)
2024-10-24T18:19:45.7651758Z updater | 2024/10/24 18:19:45 INFO <job_906158683> Updating Dapper from 2.0.35 to 2.1.35
2024-10-24T18:19:46.1115498Z   proxy | 2024/10/24 18:19:46 [374] POST /update_jobs/906158683/record_update_job_error
2024-10-24T18:19:46.2251816Z   proxy | 2024/10/24 18:19:46 [374] 204 /update_jobs/906158683/record_update_job_error
2024-10-24T18:19:46.2262742Z updater | 2024/10/24 18:19:46 INFO <job_906158683> Handled error whilst updating Dapper: update_not_possible {:dependencies=>["Dapper"]}

[brettfo]

The current shape of the update_not_possible error only allows for the dependencies to be returned, not an explanation, as helpful as that may be. This would be a larger change, including on all of the backend telemetry to track some additional field.

[fredericboyer]

I understand it is not currently possible to provide additional context, but could you please help me understand how we could go about identifying and solving the issue preventing the update otherwise? Is there currently some other ways we could go about doing this?

[brettfo]

@fredericboyer There might be some information in the log (or we could output some messages.) Do you have a full log you can share? I'll see if I can identify any useful messages or where we could add a useful message.