search

chocolatey / home

The place to start for issues with areas of Chocolatey that are infrastructure related, or really any issues could be started here. There is also choco for the CLI client, Chocolatey GUI for the GUI.
Apache License 2.0
29 stars 10 forks source link

Decrease severity of CPMR0024 #325

Closed TheCakeIsNaOH closed 4 months ago

TheCakeIsNaOH commented 4 months ago

Checklist

Is Your Feature Request Related To A Problem? Please describe.

This rule is unnecessarily strict, as it blocks packages that have a prerelease label as part of their name. https://community.chocolatey.org/packages/betaflight-configurator https://community.chocolatey.org/packages/alphacloud.msbuild.xslt.portable

It causes unnecessary work on both maintainers and moderators part as then every version has to be commented on by the maintainer and then exempted by the moderator.

Additionally, if a user has the community validation extension installed, then this blocks internalization of those packages, as they cannot be re-packed. The only workaround (without install directory hackery) is to completely uninstall and then re-install the validation extension.

Describe The Solution. Why is it needed?

The rule severity could be decreased, or a list of exemptions for the rule could be created.

Additional Context

No response

Related Issues

pauby commented 4 months ago

This rule is unnecessarily strict, as it blocks packages that have a prerelease label as part of their name.

The goal is to stop packages, with 'prerelease names' in their title, from being pushed / approved on the Chocolatey Community Repository.

If the severity of the rule is changed, it can be ignored and would need to be managed manually. That requires additional manual effort and opens up the potential for inconsistent application, which would increase this:

It causes unnecessary work on both maintainers and moderators part

If the rule severity is reduced, what are the implications, and how do we still ensure that packages with prerelease names are not submitted / approved?

Additionally, if a user has the community validation extension installed, then this blocks internalization of those packages, as they cannot be re-packed.

The Community Validation Extension is intended for use when pushing packages to the Chocolatey Community Repository. Organizations that are internalizing packages and pushing to the Chocolatey Community Repository are uncommon, and my suggestion is not to install the Community Validation Extension in those cases (not install / uninstall but not to install in the first place).

The rule severity could be decreased, or a list of exemptions for the rule could be created.

Do you mean a list of individual package names could be created to allow them to be exempt from the rule?

TheCakeIsNaOH commented 4 months ago

The goal is to stop packages, with 'prerelease names' in their title, from being pushed / approved on the Chocolatey Community Repository.

It is currently failing in large part in prevention, as prerelease versioned packages bypass approval, and get exempted automatically even if they fail the validator.

Only if a package has a prerelease component in the name, and has a normal release version does the validator rule come into effect.

If the rule severity is reduced, what are the implications, and how do we still ensure that packages with prerelease names are not submitted / approved?

The implication would be that moderators would need to check the ID of the first version of a package for prerelease components. It would be caught by the verifier, and moderators are already supposed to check the ID on the first version.

Organizations that are internalizing packages and pushing to the Chocolatey Community Repository are uncommon, and my suggestion is not to install the Community Validation Extension in those cases (not install / uninstall but not to install in the first place).

I would disagree with the implied assumption that only organizations are internalizing packages. Internalization is not limited to only the licensed extension, as packages can be internalized outside of the licensed extension, and I know of more than one person internalizing packages not for an organization.

I guess this is a valid solution, for those that are internalizing.

Do you mean a list of individual package names could be created to allow them to be exempt from the rule?

Correct. I would expect the list to be very small, and not change very much.

Another solution would be to allow disabling of extensions: https://github.com/chocolatey/choco/issues/2775

pauby commented 4 months ago

It is currently failing in large part in prevention, as prerelease versioned packages bypass approval, and get exempted automatically even if they fail the validator. Only if a package has a prerelease component in the name, and has a normal release version does the validator rule come into effect.

We are looking into that aspect and will be making changes that affect different aspects of prerelease packages.

The implication would be that moderators would need to check the ID of the first version of a package for prerelease components. It would be caught by the verifier, and moderators are already supposed to check the ID on the first version.

As we automate more and more of the process, the goal is to move away from these types of manual checks.

I would disagree with the implied assumption that only organizations are internalizing packages.

Agreed. But it is largely organizations. I've amended my statement:

The Community Validation Extension is intended for use when pushing packages to the Chocolatey Community Repository. Organizations / people that are internalizing packages and pushing to the Chocolatey Community Repository are uncommon, and my suggestion is not to install the Community Validation Extension in those cases (not install / uninstall but not to install in the first place).

Internalization is not limited to only the licensed extension, as packages can be internalized outside of the licensed extension, and I know of more than one person internalizing packages not for an organization.

The Chocolatey Community Validation is not aimed at people or organizations that are internalizing packages and pushing to the Chocolatey Community Repository. It has a very strict use case: pushing packages only to the Chocolatey Community Repository. If you are pushing packages to multiple places, then you are going to run into issues like this occasionally, and I would suggest you do not install it.

Correct. I would expect the list to be very small, and not change very much.

That moves us away from our goal of automating the process. It also requires significant work to implement. This isn't something we would look to do.

We are looking to change the type of matching the rule performs that may make it less strict. To be clear, we are not intending to change the rule severity.

TheCakeIsNaOH commented 4 months ago

If you are pushing packages to multiple places, then you are going to run into issues like this occasionally, and I would suggest you to do not install it.

Fair enough. choco-nuspec-checker does have a place then.

We are looking to change the type of matching the rule performs that may make it less strict.

That could work, depending on the type of changes.

To be clear, we are not intended to change the rule severity.

I guess this issue should be closed then.