@TravisEz13 Will we get cgmanifest error always in such PRs?

@iSazonov yes, cgmanifest will need to be update for all of these PRs. there is a file in the Action you can use to update the branch.

This PR has 6 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

Label      : Extra Small
Size       : +3 -3
Percentile : 2.4%

Total files changed: 2

Change summary by file extension:
.json : +2 -2
.csproj : +1 -1

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

Perhaps we can create a new action that updates both together ...

@iSazonov yes, cgmanifest will need to be update for all of these PRs. there is a file in the Action you can use to update the branch.

Thanks for clarify!

If we already have daily cgmanifest update why do we need this in every PR? Specially PRs such this don't add new entities, they only update minor version number.
While .Net is in a preview we will get a lot of such PRs. I think makes sense to automate or change the workflow.

@iSazonov the cgmanifest should always be up to date. We don't have a daily update as that would mean there would be a time that it is out of sync with the code.

I'm saying we disable dependabot, run dotnet-outdated to update all package references and then run the script to update cgmanifest and submit a PR if there are any changes. replacing dependabot, not this GitHub Action.

We could probably update or add a GH action that updates the PR based on a comment in the PR with the correct cgmanifest. I think this might be better as we don't have to re-invent dependabot.

I'm on vacation, the rebase triggers a comment. there is a -fix on the script to check the cgmanifest, and the daily workflow has the code to submit a PR.

I don't understand why should we update the cgmanifest with every commit? Daily action can do this work and keep the manifest file up-to-date.
I don't see the process being so strong in other repositories.
Or if MSFT team want to be so strong we could remove the step from anywhere and create GH Action triggered by new merged commit.

As far as I know, we are the only repo that must use CG manifest in place of detection. It is a false comparison. We can update at the end of the day, but it will mean that are releases will be delayed by two days. We need to identify problems with the notice file as soon as possible before the release as to not delay the release.

we update the cgmanifest with every commit
Only commits that modify the packages used by the product. If a package was added and not just a version change, this requires human review to determine if the dependency is a development dependency like StyleCop.
You are taking a small sub-set of PRs and acting like

Or if MSFT team wants to be so strong we could remove the step from anywhere and create GH Action triggered by new merged commit.
Who would be responsible for the PRs generated by the action? And this still means for some time after the PR that the code would not be correct. I'm sorry but it needs to be correct with the PR.

I'm sorry but we have one case where this is a significant issue, dependabot, that can be dealt with separately.

🎉v7.3.0-preview.1 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes