[pull] main from Azure:main #2

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.

* Use the new code generator to generate SDK code from TSP. * updated

Co-authored-by: Praveen Kuttappan <praveen.kuttappan@gmail.com>

* tests for hierarchy build * Added missing scenario

Co-authored-by: Wes Haggard <weshaggard@users.noreply.github.com>

* AOAI 2.8.0 compat * Remove unused variable in TwoTurnCrossModel test (#54493) * Initial plan * Remove unused options variable from TwoTurnCrossModel test Co-authored-by: trrwilson <35748617+trrwilson@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: trrwilson <35748617+trrwilson@users.noreply.github.com> --------- Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com>

…alpha.20251211.2 (#54464) * Regenerate repository SDK with TypeSpec build 20251211.2 * Update SDK code sc_wo_4 * Update SDK code co_dy_1 * Update SDK code mo_re_3 * Update SDK code ea_mo_2 * Update SDK code ag_co_0

…ons.list (#54450) Co-authored-by: ArcturusZhang <10554446+ArcturusZhang@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>

* fix bug in safe flattern * address review comment

* Initial plan * Fix nullable value type serialization for ResourceType - Updated SerializationExpression delegate to include CSharpType valueType parameter - Modified SerializeTypeWithImplicitOperatorToString to call NullableStructValue for nullable value types - Updated ManagementTypeFactory.SerializeJsonValue to pass valueType to serialization expression - Verified fix by regenerating test projects successfully Co-authored-by: live1206 <5196139+live1206@users.noreply.github.com> * Add test model for nullable ResourceType serialization Added ResourceTypeTestResource model with optional armResourceType property to test nullable value type serialization. The test model is included in the Mgmt-TypeSpec test project to verify the fix. Note: Further investigation needed as generated code still shows .Value accessor despite the fix being in place. This may require deeper analysis of the TypeSpec generator framework's expression generation. Co-authored-by: live1206 <5196139+live1206@users.noreply.github.com> * Merge main branch and resolve conflicts - Merged latest changes from main branch - Resolved conflict in tspCodeModel.json by accepting main version and regenerating - Regenerated test project to include testresourcetype.tsp with updated main branch changes - All test models including ResourceTypeTestResource are properly integrated Co-authored-by: live1206 <5196139+live1206@users.noreply.github.com> * regen --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: live1206 <5196139+live1206@users.noreply.github.com> Co-authored-by: Wei Hu <huwe@microsoft.com>

….0.0-alpha.20251214.3 (#54520) * Regenerate repository SDK with TypeSpec build 20251214.3 * Update SDK code sc_wo_4 * Update SDK code mo_re_3 * Update SDK code ea_mo_2 * Update SDK code co_dy_1 * Update SDK code ag_co_0

* Initial plan * Fix interface without get operation generation issue Added logic to set resourceIdPattern from Action/List operations when no CRUD operations exist and there's no parent resource. Co-authored-by: live1206 <5196139+live1206@users.noreply.github.com> * Refactor fix: treat operations without CRUD as non-resource methods Changed approach to treat resource operations without CRUD operations and without parent as non-resource methods (extension methods), rather than trying to infer resourceIdPattern. Co-authored-by: live1206 <5196139+live1206@users.noreply.github.com> * Regenerate test projects after removing PrivateLinks operations Co-authored-by: live1206 <5196139+live1206@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: live1206 <5196139+live1206@users.noreply.github.com>

* Update UnbrandedGeneratorVersion to 1.0.0-alpha.20251211.7 * npm install * fix test * fix test * fix strange test failure * add new spector projects and regen * update debug profiles * update tspcodemodels --------- Co-authored-by: Ubuntu <cloudtest@5cb176c3c000005.tkkhlgj2u51eln3mcb0lygmbye.dx.internal.cloudapp.net> Co-authored-by: jolov <jolov@microsoft.com> Co-authored-by: Jorge Rangel <jorgerangel@microsoft.com>

…Actions (#54521)

… PR (#54482) * script change work before change .net management sdk Gen required in spec pr. * remove inaccurate comment.

) Co-authored-by: Juan Ospina <70209456+jeo02@users.noreply.github.com>

* initiate first version sdk * run compile command again * initialization for the subclients * suppress four getSubClient features and create new ones * updated all tests and samples * added new samples * added all md samples for authoring and update snippets * add assets.json * update tsp-location.yaml * move authoring to general sln * updated csharp sdk to restore structures * retore client structures * updated snippets * updated commit id * updated changelog * add compatibility for 2025-11-01 * updated changelog * run Export-API.ps1 * update patch function * add introduction for the 2025-11-01 * updated changelog * updated readme * updated samples readme * updated feature names * replace deployment resources with project resources

…alpha.20251215.1 (#54534) * Regenerate repository SDK with TypeSpec build 20251215.1 * Update SDK code mo_re_3 * Update SDK code ea_mo_2 * fix health tests --------- Co-authored-by: Jorge Rangel <jorgerangel@microsoft.com>

* temp * refactor: only update enum ns in PreVisitEnum

* Update UnbrandedGeneratorVersion to 1.0.0-alpha.20251212.3 * update package lock --------- Co-authored-by: Ubuntu <cloudtest@3bf27eaec000005.tkkhlgj2u51eln3mcb0lygmbye.dx.internal.cloudapp.net> Co-authored-by: Jorge Rangel <jorgerangel@microsoft.com>

…1` (#54479)

… with Data (#54530) * Initial plan * Add test resource ending with Data and fix ResourceVisitor Co-authored-by: live1206 <5196139+live1206@users.noreply.github.com> * Add unit test for resource model ending with Data Co-authored-by: live1206 <5196139+live1206@users.noreply.github.com> * Use StringComparison.Ordinal for EndsWith check Co-authored-by: live1206 <5196139+live1206@users.noreply.github.com> * Revert changes to NameVisitorTests.cs - test is in TypeSpec project Co-authored-by: live1206 <5196139+live1206@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: live1206 <5196139+live1206@users.noreply.github.com>

* pull doc fixes from latest tsp * fix generated TextTranslationClientBuilder * export api update * update docs + links * update generated apis --------- Co-authored-by: Jiarui Guo <jiarguo@microsoft.com>

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 December 12, 2025 15:49

bump to latest Azure.Generator (#54480)

dfec5fc

MPG migration - SecretsStoreExtension (#54244)

ab5fd4d

* Use the new code generator to generate SDK code from TSP. * updated

fix serialization for enum (#54485)

c949a7e

Add a step explicitly to verify setup (#54487)

cd673e0

Co-authored-by: Praveen Kuttappan <praveen.kuttappan@gmail.com>

tests for hierarchy build (#54459)

d553aef

* tests for hierarchy build * Added missing scenario

Add 'APIView prod deployment' to internal service connections (#54490)

5135db1

Co-authored-by: Wes Haggard <weshaggard@users.noreply.github.com>

[Azure Mgmt Generator] Auto omit Azure.ResourceManager.Legacy.Operati…

744be65

…ons.list (#54450) Co-authored-by: ArcturusZhang <10554446+ArcturusZhang@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>

fix bug in safe flatten (#54514)

51ade19

* fix bug in safe flattern * address review comment

Bump tsp and azure generator (#54522)

586a203

Regenerate repository SDK with TypeSpec build 20251214.4 (#54524)

0ab50ff

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

ba35a99

…Actions (#54521)

Script changes before making .NET management sdk Gen required in Spec…

08fe5b6

… PR (#54482) * script change work before change .net management sdk Gen required in spec pr. * remove inaccurate comment.

Update paths to include all files in .github directory for evals (#54535

513b829

) Co-authored-by: Juan Ospina <70209456+jeo02@users.noreply.github.com>

Update namespace visitor (#54473)

b5bd663

* temp * refactor: only update enum ns in PreVisitEnum

Regenerate repository SDK with TypeSpec build 20251215.3 (#54539)

b02d00f

[ResourceManager] Bump api-version of ManagementGroup to `2023-04-0…

b3a85e2

…1` (#54479)

fix lock file for mgmt (#54531)

5484333

Prepare release for Azure.ResourceManager.StorageSync (#54543)

12f082c

[Text Translation] Update docs & links and some fixes (#54471)

207e99d

* pull doc fixes from latest tsp * fix generated TextTranslationClientBuilder * export api update * update docs + links * update generated apis --------- Co-authored-by: Jiarui Guo <jiarguo@microsoft.com>

remove @typespec/http-client-csharp from mgmt emitter pinning (#54547)

bb5e1c0

[pull] main from Azure:main #2

Are you sure you want to change the base?

[pull] main from Azure:main #2

Uh oh!

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

pull bot commented Jul 20, 2021 •

edited

Loading

commit-lint bot commented Jul 20, 2021 •

edited

Loading