[pull] main from helm:main #1

pull · 2021-07-22T20:47:26Z

See Commits and Changes for more details.

Created by pull[bot]

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

commit-lint · 2021-07-22T20:47:31Z

Chore

deps: bump github.com/BurntSushi/toml from 0.4.1 to 1.0.0 (583c4ac)

Code Refactoring

use os.ReadDir for lightweight directory reading (e12f357)

Contributors

sabre1041, scottrigby, mattfarina, dependabot[bot], runyontr, dperaza4dustbit, matthiasfehr, Juneezee, hickeyma, jdolitsky

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:03Z

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

commit-lint · 2022-11-08T20:54:14Z

Documentation

add an example for using the upgrade command with existing values (e35bf1f)

Oci

Add flag --plain-http to enable working with HTTP registries (2538b92)
add tests for plain HTTP and insecure HTTPS registries (6defb96)

Chore

deps: bump github.com/opencontainers/runc from 1.1.4 to 1.1.5 (2bfc367)
deps: bump oras.land/oras-go from 1.2.2 to 1.2.3 (d8caa67)
deps: bump github.com/rubenv/sql-migrate from 1.3.1 to 1.5.1 (d0febd5)
fix a typo in manager.go (15e6066)

Contributors

joejulian, mih-kopylov, mattfarina, josegonzalez, aryan9600, dependabot[bot], wujunwei, yardenshoham, sabre1041, gjenkins8, jmhbnz

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

pull-request-quantifier-deprecated · 2024-01-24T17:55:31Z

This PR has 12470 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       : +9108 -3362
Percentile : 100%

Total files changed: 424

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +466 -4
.gitignore : +1 -0
.md : +23 -12
.go : +7468 -3022
.txt : +516 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-02-14T19:55:39Z

This PR has 12540 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       : +9178 -3362
Percentile : 100%

Total files changed: 429

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +472 -4
.gitignore : +1 -0
.md : +23 -12
.go : +7532 -3022
.txt : +516 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-02-19T16:26:30Z

This PR has 12577 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       : +9214 -3363
Percentile : 100%

Total files changed: 429

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +472 -4
.gitignore : +1 -0
.md : +23 -12
.go : +7568 -3023
.txt : +516 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-02-21T20:10:37Z

This PR has 12587 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       : +9224 -3363
Percentile : 100%

Total files changed: 429

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +472 -4
.gitignore : +1 -0
.md : +23 -12
.go : +7578 -3023
.txt : +516 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-02-28T18:10:36Z

This PR has 12587 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       : +9224 -3363
Percentile : 100%

Total files changed: 429

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +472 -4
.gitignore : +1 -0
.md : +23 -12
.go : +7578 -3023
.txt : +516 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-01T20:39:14Z

This PR has 12588 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       : +9225 -3363
Percentile : 100%

Total files changed: 429

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +472 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7578 -3023
.txt : +516 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-10T14:23:18Z

This PR has 12588 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       : +9225 -3363
Percentile : 100%

Total files changed: 429

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +472 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7578 -3023
.txt : +516 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-11T18:23:13Z

This PR has 12588 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       : +9225 -3363
Percentile : 100%

Total files changed: 429

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +472 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7578 -3023
.txt : +516 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-11T20:28:18Z

This PR has 12596 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       : +9232 -3364
Percentile : 100%

Total files changed: 429

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +472 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7585 -3024
.txt : +516 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-11T20:45:41Z

This PR has 12596 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       : +9232 -3364
Percentile : 100%

Total files changed: 429

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +472 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7585 -3024
.txt : +516 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-13T14:26:54Z

This PR has 12596 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       : +9232 -3364
Percentile : 100%

Total files changed: 429

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +472 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7585 -3024
.txt : +516 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-14T13:55:29Z

This PR has 12815 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       : +9447 -3368
Percentile : 100%

Total files changed: 435

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +488 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7740 -3028
.txt : +560 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-14T17:23:40Z

This PR has 12846 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       : +9476 -3370
Percentile : 100%

Total files changed: 435

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +488 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7769 -3030
.txt : +560 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-14T17:33:45Z

This PR has 12847 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       : +9477 -3370
Percentile : 100%

Total files changed: 435

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +488 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7770 -3030
.txt : +560 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-14T17:34:02Z

This PR has 12847 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       : +9477 -3370
Percentile : 100%

Total files changed: 435

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +488 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7770 -3030
.txt : +560 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-14T17:37:41Z

This PR has 12847 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       : +9477 -3370
Percentile : 100%

Total files changed: 435

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +488 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7770 -3030
.txt : +560 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-14T17:37:48Z

This PR has 12847 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       : +9477 -3370
Percentile : 100%

Total files changed: 435

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +488 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7770 -3030
.txt : +560 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-14T17:37:49Z

This PR has 12847 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       : +9477 -3370
Percentile : 100%

Total files changed: 435

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +488 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7770 -3030
.txt : +560 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-14T17:38:09Z

This PR has 12847 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       : +9477 -3370
Percentile : 100%

Total files changed: 435

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +488 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7770 -3030
.txt : +560 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-22T14:36:38Z

This PR has 12928 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       : +9558 -3370
Percentile : 100%

Total files changed: 438

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +488 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7851 -3030
.txt : +560 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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-03-22T14:38:08Z

This PR has 12928 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       : +9558 -3370
Percentile : 100%

Total files changed: 438

Change summary by file extension:
.sh : +10 -61
.yml : +154 -66
.yaml : +488 -4
.gitignore : +2 -0
.md : +23 -12
.go : +7851 -3030
.txt : +560 -62
.json : +43 -0
.mod : +157 -38
.helmignore : +23 -0
.crt : +80 -17
.key : +81 -25
.pem : +27 -27
Makefile : +20 -16
OWNERS : +12 -4
cmd/helm/testdata/password : +1 -0
scripts/get : +7 -3
scripts/get-helm-3 : +19 -5

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.

…/checkout-4.2.2 Bump actions/checkout from 4.2.1 to 4.2.2

…42d6f8 Bump the k8s-io group with 7 updates

chore: Check tar is installed install script

ISSUE-9507: ADD `application/gzip,application/octet-stream` accept header

fix: Use chart archive modifed time for OCI push

Signed-off-by: Tianle Xu <xtl@xtlsoft.top>

Allow tests to run on loong64

Signed-off-by: Suleiman Dibirov <idsulik@gmail.com>

fix(hooks): correct hooks delete order

Note, this runner is provided as part of the CNCF access to GitHub Enterprise runners. Signed-off-by: Matt Farina <matt.farina@suse.com>

Increasing the size of the runner used for releases.

…/stale-9.0.0 chore(deps): bump actions/stale from 3.0.14 to 9.0.0

Signed-off-by: Zach Burgess <zachburg@google.com>

Signed-off-by: Alex Johnson <alex.kattathra.johnson@gmail.com>

Fix typo in pkg/lint/rules/chartfile_test.go

Add tests to `helm/pkg/kube/client_test.go` to cover `wait.go`

In the event some malformed folders/files make its way into the `charts/` directory meant for subcharts, it is possible one may see an error message like the below: ``` Error: error unpacking foo in app: Chart.yaml file is missing ``` This error is not very descriptive, as it doesn't reference where on disk `Chart.yaml` is missing. In the event this happens, this error is being updated to include that `Chart.yaml` is missing for the `foo` subchart. Without this updated error messaging, one would need to look into Helm's codebase to troubleshoot what exactly is wrong. Signed-off-by: Taylor Jasko <taylor@taylorjasko.com>

Signed-off-by: wangjingcun <wangjingcun@aliyun.com>

Signed-off-by: mathieu cesbron <mathieu.rudy.cesbron@gmail.com>

Updating subchart load error to be more descriptive

fix: fix label name

Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.28.0 to 0.29.0. - [Commits](golang/crypto@v0.28.0...v0.29.0) --- updated-dependencies: - dependency-name: golang.org/x/crypto dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>

When the main branch is for Helm v4, the dev-v3 branch is for Helm v3. Note, the canary release is setup for helm v4 once the v3 branch is created and there is no canary release for v3. Signed-off-by: Matt Farina <matt.farina@suse.com>

Adding CI for dev-v3 branch

…x/crypto-0.29.0 Bump golang.org/x/crypto from 0.28.0 to 0.29.0

Bumps [github.com/distribution/distribution/v3](https://github.com/distribution/distribution) from 3.0.0-20221208165359-362910506bc2 to 3.0.0-rc.1. - [Release notes](https://github.com/distribution/distribution/releases) - [Commits](https://github.com/distribution/distribution/commits/v3.0.0-rc.1) --- updated-dependencies: - dependency-name: github.com/distribution/distribution/v3 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>

The README and contributing document now directly address Helm v4 and v3 to direct contributors. Signed-off-by: Matt Farina <matt@mattfarina.com>

…distribution/distribution/v3-3.0.0-rc.1 Bump github.com/distribution/distribution/v3 from 3.0.0-20221208165359-362910506bc2 to 3.0.0-rc.1

Fix typo "re-use" to "reuse"

Updating docs around v3 and v4

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

pull bot added ⤵️ pull and removed Large labels Jul 22, 2021

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

pull-request-quantifier-deprecated bot added Extra Large and removed Large labels Aug 19, 2021

robertsirc and others added 30 commits October 25, 2024 15:09

Merge pull request #13408 from helm/dependabot/github_actions/actions…

351f552

…/checkout-4.2.2 Bump actions/checkout from 4.2.1 to 4.2.2

Merge pull request #13407 from helm/dependabot/go_modules/k8s-io-b013…

3cca969

…42d6f8 Bump the k8s-io group with 7 updates

Merge pull request #13403 from banjoh/em/check-tar

86102f0

chore: Check tar is installed install script

Merge pull request #13034 from mattclegg/issue-9507

5ae91e1

ISSUE-9507: ADD `application/gzip,application/octet-stream` accept header

Merge pull request #13376 from helm/fix_oci_push_timestamp

717529a

fix: Use chart archive modifed time for OCI push

Allow tests to run on loong64

a51ea6e

Signed-off-by: Tianle Xu <xtl@xtlsoft.top>

Merge pull request #13412 from xtlsoft/main

d2ae7d0

Allow tests to run on loong64

fix(hooks): correct hooks delete order

f4f4a6b

Signed-off-by: Suleiman Dibirov <idsulik@gmail.com>

Merge pull request #13365 from idsulik/issue-13363

2848e3d

fix(hooks): correct hooks delete order

Increasing the size of the runner used for releases.

029e983

Note, this runner is provided as part of the CNCF access to GitHub Enterprise runners. Signed-off-by: Matt Farina <matt.farina@suse.com>

Merge pull request #13416 from mattfarina/build-release-bigger-runner

fab22eb

Increasing the size of the runner used for releases.

Merge pull request #12620 from helm/dependabot/github_actions/actions…

261233c

…/stale-9.0.0 chore(deps): bump actions/stale from 3.0.14 to 9.0.0

Fix typo in pkg/lint/rules/chartfile_test.go

0cc78c6

Signed-off-by: Zach Burgess <zachburg@google.com>

Add tests to helm/pkg/kube/client_test.go to cover wait.go

9fd943b

Signed-off-by: Alex Johnson <alex.kattathra.johnson@gmail.com>

Merge pull request #13420 from zachburg/main

7b62210

Fix typo in pkg/lint/rules/chartfile_test.go

Merge pull request #13418 from alex-kattathra-johnson/issue-13417

106e2f9

Add tests to `helm/pkg/kube/client_test.go` to cover `wait.go`

fix: fix label name

e4062e7

Signed-off-by: wangjingcun <wangjingcun@aliyun.com>

Fix typo "re-use" to "reuse"

fc17fc7

Signed-off-by: mathieu cesbron <mathieu.rudy.cesbron@gmail.com>

Merge pull request #13423 from tjasko/bug/subchart-error-messaging

cf871d2

Updating subchart load error to be more descriptive

Merge pull request #13424 from wangjingcun/main

2aba8a1

fix: fix label name

Adding CI for dev-v3 branch

b5a83ea

When the main branch is for Helm v4, the dev-v3 branch is for Helm v3. Note, the canary release is setup for helm v4 once the v3 branch is created and there is no canary release for v3. Signed-off-by: Matt Farina <matt.farina@suse.com>

Merge pull request #13432 from mattfarina/ci-for-v3

aded0ac

Adding CI for dev-v3 branch

Merge pull request #13428 from helm/dependabot/go_modules/golang.org/…

dd35343

…x/crypto-0.29.0 Bump golang.org/x/crypto from 0.28.0 to 0.29.0

Updating docs around v3 and v4

8bc122e

The README and contributing document now directly address Helm v4 and v3 to direct contributors. Signed-off-by: Matt Farina <matt@mattfarina.com>

Merge pull request #13426 from helm/dependabot/go_modules/github.com/…

a9187bd

…distribution/distribution/v3-3.0.0-rc.1 Bump github.com/distribution/distribution/v3 from 3.0.0-20221208165359-362910506bc2 to 3.0.0-rc.1

Merge pull request #13425 from MathieuCesbron/main

21568de

Fix typo "re-use" to "reuse"

Merge pull request #13443 from mattfarina/update-docs-v4

ecc4ade

Updating docs around v3 and v4

[pull] main from helm:main #1

Are you sure you want to change the base?

[pull] main from helm:main #1

Conversation

pull bot commented Jul 22, 2021 • edited Loading

commit-lint bot commented Jul 22, 2021 • edited Loading

Chore

Code Refactoring

Contributors

mergify bot commented Apr 15, 2022

commit-lint bot commented Nov 8, 2022 • edited Loading

Documentation

Oci

Chore

Contributors

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

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 14, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 19, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Feb 21, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

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

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 1, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 10, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 11, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 11, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 11, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 13, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 14, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 14, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 14, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 14, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 14, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 14, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 14, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 14, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 22, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull-request-quantifier-deprecated bot commented Mar 22, 2024

What can I do to optimize my changes

How to interpret the change counts in git diff output

pull bot commented Jul 22, 2021 •

edited

Loading

commit-lint bot commented Jul 22, 2021 •

edited

Loading

commit-lint bot commented Nov 8, 2022 •

edited

Loading