[pull] main from Azure:main by pull[bot] · Pull Request #2 · Blaquez-home/azure-sdk-for-net

pull · 2021-07-20T03:02:09Z

See Commits and Changes for more details.

Can you help keep this open source service alive? 💖 Please sponsor : )

commit-lint · 2021-07-20T03:02:12Z

Bug Fixes

sdk: excessive entries in changelog (fix(sdk): excessive entries in changelog Azure/azure-sdk-for-net#39669) (2e16815)

Contributors

hallipr, azure-sdk, rhorber, drielenr, rajkumar-rangaraj, TimothyMothra, ArcturusZhang, jsquire, williamzhao87, JoshLove-msft, amnguye, paulroho, joseharriaga, trrwilson, m-nash, jalauzon-msft, archerzz

Commit-Lint commands

You can trigger Commit-Lint actions by commenting on this PR:

@Commit-Lint merge patch will merge dependabot PR on "patch" versions (X.X.Y - Y change)
@Commit-Lint merge minor will merge dependabot PR on "minor" versions (X.Y.Y - Y change)
@Commit-Lint merge major will merge dependabot PR on "major" versions (Y.Y.Y - Y change)
@Commit-Lint merge disable will desactivate merge dependabot PR
@Commit-Lint review will approve dependabot PR
@Commit-Lint stop review will stop approve dependabot PR

mergify · 2022-04-15T13:29:15Z

@pull-request-quantifier[bot] is not allowed to run commands

pull-request-quantifier-deprecated · 2024-01-28T20:13:46Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-29T05:47:26Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-29T13:15:02Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-29T13:15:02Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-29T13:15:06Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-29T13:15:21Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-29T13:15:22Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-29T13:15:31Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-29T20:35:03Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-29T20:35:34Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-29T22:07:28Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-30T01:21:51Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-30T07:04:16Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-30T07:04:19Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-30T07:51:20Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-30T17:08:55Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-30T18:20:51Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-30T23:50:35Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-31T00:02:16Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-31T00:02:49Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-31T01:34:00Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-31T01:40:35Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-31T02:23:39Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-31T03:48:49Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-31T05:59:39Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

pull-request-quantifier-deprecated · 2024-01-31T07:40:25Z

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

Quantification details

Label      : Extra Large
Size       : +2377 -645
Percentile : 100%

Total files changed: 30

Change summary by file extension:
.json : +1011 -14
.sh : +0 -174
.editorconfig : +4 -2
.txt : +309 -0
.yml : +484 -7
.md : +139 -195
.config : +23 -0
.gitignore : +9 -2
.vsconfig : +14 -0
.Config : +0 -4
.devcontainer/Dockerfile : +0 -15
.github/CODEOWNERS : +384 -232

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

Fast and predictable releases to production:
- Optimal size changes are more likely to be reviewed faster with fewer
  iterations.
- Similarity in low PR complexity drives similar review times.
Review quality is likely higher as complexity is lower:
- Bugs are more likely to be detected.
- Code inconsistencies are more likely to be detected.
Knowledge sharing is improved within the participants:
- Small portions can be assimilated better.
Better engineering practices are exercised:
- Solving big problems by dividing them in well contained, smaller problems.
- Exercising separation of concerns within the code changes.

What can I do to optimize my changes

Use the PullRequestQuantifier to quantify your PR accurately
- Create a context profile for your repo using the context generator
- Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
- Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
- Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
Change your engineering behaviors
- For PRs that fall outside of the desired spectrum, review the details and check if:
  - Your PR could be split in smaller, self-contained PRs instead
  - Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

One line was added: +1 -0
One line was deleted: +0 -1
One line was modified: +1 -1 (git diff doesn't know about modified, it will
interpret that line like one addition plus one deletion)
Change percentiles: Change characteristics (addition, deletion, modification)
of this PR in relation to all other PRs within the repository.

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

* Add azure-sdk-pr-review skill to .github/skills/ Move the azure-sdk-pr-review Copilot skill from local user skills to the repository .github/skills/ directory so it is available to all contributors. * Address PR review feedback - Rename skill to azure-sdk-mgmt-pr-review to reflect management-plane scope - Clarify packages are under Azure.ResourceManager.* - Reference TypeSpec (client.tsp, tspconfig.yaml) instead of only autorest.md - Update output format to add comments directly to PR via GitHub MCP tools * Remove legacy autorest.md references * Address copilot reviewer feedback - Include Azure.ResourceManager (base package) in scope - Clarify Type Formatting table for .NET API surface (Guid not uuid) - Add TypeSpec note for UUID mapping

….0.0-alpha.20260211.1 (#56186) * Regenerate repository SDK with TypeSpec build 20260211.1 * Update SDK code re_wo_4 * Update SDK code co_ed_1 * export API --------- Co-authored-by: Arthur Ma <mars.arthur@263.net> Co-authored-by: Wei Hu <huwe@microsoft.com>

…56211)

…alpha.20260211.1 (#56194) * Regenerate repository SDK with TypeSpec build 20260211.1 * Update SDK code mo_re_3 * Update SDK code ed_mo_2 * Update SDK code re_wo_4 * Update SDK code co_ed_1 * Update SDK code ad_co_0 * update snippets * update more snippets --------- Co-authored-by: Jorge Rangel <jorgerangel@microsoft.com>

Updating to correct label.

* Update UnbrandedGeneratorVersion to 1.0.0-alpha.20260212.3 * fix tests --------- Co-authored-by: Ubuntu <cloudtest@6dd5f444c000002.tkkhlgj2u51eln3mcb0lygmbye.dx.internal.cloudapp.net> Co-authored-by: Jorge Rangel <jorgerangel@microsoft.com>

…6236) Resolves #55501 - Add configurable WorkloadIdentityCredential tests that create credentials via IConfiguration and ConfigurableCredential instead of direct instantiation - Add creation tests for all 7 credential types validating option priority: IConfiguration > environment variable > default - Plumb IsAzureProxyEnabled through DefaultAzureCredentialOptions for WIC proxy support - Add shared CredentialCreationTestBase<T> with reflection helpers - Simplify helper by exposing config mapping and transport support

Co-authored-by: Matthew Sainsbury <msainsbury@microsoft.com>

* remove limits on application id length * take 2 * take 3 * fix ifs * update implementation * tweak implementation 2 * undo test change * fix ctor * tests * Apply suggestions from code review Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * feedback * add a minimum * take 3 * self review * handle a couple gaps * first pass on changing back to client options * delay validation an remove max * review * update test * remove old tests * remove config * remove eager validation test from old implementation * fix --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

* feat: add xml serialization visitor * pr feedback

…se 1.0.0-alpha.20260211.2 (#56217) * Regenerate repository SDK with TypeSpec build 20260211.2 * Update SDK code co_ed_1 * Update SDK code ed_mo_2 * Update SDK code re_wo_4 * Update SDK code mo_re_3 * Update SDK code ad_co_0 * update snippet --------- Co-authored-by: azure-sdk <azuresdk@microsoft.com>

* Initial plan * Fix CredentialSettings constructor to not throw for non-auth clients Co-authored-by: m-nash <64171366+m-nash@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: m-nash <64171366+m-nash@users.noreply.github.com>

* Update UnbrandedGeneratorVersion to 1.0.0-alpha.20260212.5 * Fix InvalidOperationException in pagination when services return relative nextLink URIs (#56249) * Initial plan * Fix relative URI handling in pagination - use IsAbsoluteUri check Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com> * Revert Spector and package-lock.json changes Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com> --------- Co-authored-by: Ubuntu <cloudtest@ff2ffbe4c000001.tkkhlgj2u51eln3mcb0lygmbye.dx.internal.cloudapp.net> Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com> Co-authored-by: JoshLove-msft <54595583+JoshLove-msft@users.noreply.github.com>

* Updated deployment setting to use http * Use parameters.AdditionalParameters in yaml --------- Co-authored-by: Chidozie Ononiwu <chononiw@microsoft.com>

…eration - .NET-5867191 (#56188)

…factSigning (#56260)

…preserving Authorization header (#55633) * Add redirect policy to CodeTransparency and ConfidentialLedger SDKs - Add CodeTransparencyRedirectPolicy to follow 307/308 redirects while preserving Authorization header - Wire redirect policy into CodeTransparencyClient constructor - Add unit tests for CodeTransparencyRedirectPolicy (11 tests) - Update CodeTransparency CHANGELOG.md - Update ConfidentialLedger CHANGELOG.md version to 1.4.1-beta.3 * update changelog * fix pipeline * fix pipeline * Update sdk/confidentialledger/Azure.Security.CodeTransparency/CHANGELOG.md Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update sdk/confidentialledger/Azure.Security.CodeTransparency/src/CodeTransparencyRedirectPolicy.cs Co-authored-by: Andrea Piccione <and.piccione@gmail.com> * Update sdk/confidentialledger/Azure.Security.CodeTransparency/src/CodeTransparencyRedirectPolicy.cs Co-authored-by: Andrea Piccione <and.piccione@gmail.com> * Update sdk/confidentialledger/Azure.Security.CodeTransparency/src/CodeTransparencyRedirectPolicy.cs Co-authored-by: Andrea Piccione <and.piccione@gmail.com> --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Andrea Piccione <and.piccione@gmail.com>

…greSql (#56214)

Co-authored-by: Ubuntu <cloudtest@758eeaa5c000004.tkkhlgj2u51eln3mcb0lygmbye.dx.internal.cloudapp.net>

) * Support credential instance reuse in WithAzureCredential DI path (#56231) * Refactor credential cache: encapsulate key creation in GetOrAdd and simplify to StringBuilder * Share credential cache globally across DI and direct ClientSettings paths with lazy initialization

…alpha.20260213.1 (#56272) * Regenerate repository SDK with TypeSpec build 20260213.1 * Update SDK code ed_mo_2 * Update SDK code co_ed_1 * Update SDK code re_wo_4 * Update SDK code mo_re_3 * Update SDK code ad_co_0

Co-authored-by: Ubuntu <cloudtest@8c6b791ec000002.tkkhlgj2u51eln3mcb0lygmbye.dx.internal.cloudapp.net>

* migrate AnomalyDetector * Migrate to new generator * Regeneration after Endpoint is changed from string to url in main.tsp * fix tests * change commit to latest * changes after running update snippets and export API scripts * Generator migration script * rerun Library_Inventory.ps1 * Regenerate anomalydetector SDK serialization code * Regenerate anomalydetector serialization code to match current generator output * rerun library inventory script --------- Co-authored-by: Linh Phan <mailinhphan@microsoft.com>

* Add bump-mgmt-base-version Copilot skill Adds a reusable Copilot skill for bumping the http-client-csharp base dependency version in http-client-csharp-mgmt. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix step numbering in skill file Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Updates @azure-typespec/http-client-csharp and AzureGeneratorVersion from 1.0.0-alpha.20260209.2 to 1.0.0-alpha.20260213.2. Includes prettier fixes and regenerated test projects. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Regenerate SDK from spec commit 1d0c547 and fix tests - Regenerate SDK code using tsp-client update with local spec repo - Update typed response models (AssetStatisticsResponse, QueryableDefinitionsResponse, TilerAssetGeoJson) - Fix test and sample compilation: use .AdditionalProperties for dictionary access - Update tsp-location.yaml to spec commit 1d0c54799082b9cbe46d984069f673b7013b3c59 - Update public API listings * Generate API

pull bot added the ⤵️ pull label Jul 20, 2021

pull-request-quantifier-deprecated bot added the Extra Large label Jul 20, 2021

live1206 and others added 30 commits February 12, 2026 10:33

Remove show-serialized-names debug config and regenerate PostgreSql (#…

c0e0920

…56211)

Update labels for Azure Load Testing service (#56206)

86026ec

Updating to correct label.

Clarify that multiple calls to UseAzureMonitor is not allowed (#56235)

5fef03a

Co-authored-by: Matthew Sainsbury <msainsbury@microsoft.com>

Add xml serialization visitor (#56200)

aafef0c

* feat: add xml serialization visitor * pr feedback

Remote AOT ci parameters from planetarycomputer (#56238)

5e9cdff

Increment package version after release of Azure.Compute.Batch (#56246)

5d0045c

Sync eng/common directory with azure-sdk-tools for PR 13968 (#56247)

c84409e

* Updated deployment setting to use http * Use parameters.AdditionalParameters in yaml --------- Co-authored-by: Chidozie Ononiwu <chononiw@microsoft.com>

[AutoPR Azure.ResourceManager.ArtifactSigning]-generated-from-SDK Gen…

d2578ad

…eration - .NET-5867191 (#56188)

Increment package version after release of Azure.ResourceManager.Arti…

c51349b

…factSigning (#56260)

Generator Agent (#55597)

b996f39

Increment package version after release of Azure.ResourceManager.Post…

440a0b4

…greSql (#56214)

Update UnbrandedGeneratorVersion to 1.0.0-alpha.20260213.1 (#56265)

8d2b5b7

Co-authored-by: Ubuntu <cloudtest@758eeaa5c000004.tkkhlgj2u51eln3mcb0lygmbye.dx.internal.cloudapp.net>

Update UnbrandedGeneratorVersion to 1.0.0-alpha.20260213.8 (#56274)

9d2dd76

Co-authored-by: Ubuntu <cloudtest@8c6b791ec000002.tkkhlgj2u51eln3mcb0lygmbye.dx.internal.cloudapp.net>

Regenerate repository SDK with TypeSpec build 20260213.2 (#56280)

5dc891a

Conversation

pull bot commented Jul 20, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

commit-lint bot commented Jul 20, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Bug Fixes

Contributors

Uh oh!

mergify bot commented Apr 15, 2022

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 28, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 29, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 30, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 30, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 30, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 30, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 30, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 30, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

Uh oh!

pull-request-quantifier-deprecated bot commented Jan 30, 2024

pull bot commented Jul 20, 2021 •

edited

Loading

commit-lint bot commented Jul 20, 2021 •

edited

Loading