@fejta-bot: Closing this issue.

<details>

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community. /close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. </details>

Currently, our plugin manifest validation functionality which is in the YAML parsing path has some style/cosmetic checks that have no effect on plugin installation. This is a result of not separating "cosmetic validation" and "functional validation".

If we continue on this trajectory, we will be adding more "cosmetic validation" in future versions, which will break older plugin manifests. So we can't do that. Furthermore, with custom plugin indexes (#566), we cannot control the plugin manifests out in the wild –but we have to be able to continue working with them.

I propose that we strip off these "cosmetic validations" from the logic in krew machinery, and create a krew_index_manifest_validator tool, specifically for krew-index that runs as part of its CI for each PR.

This would help reduce code review toil we have been manually enforcing in krew-index, as well as separate structural validation vs cosmetic validation, such as:

• shortDescription must not contain line break characters
• shortDescription must not have a a trailing period (.)
• description must be wrapped at 80 character lines
• explicit files: {from: '*', to: '.'} is not needed, drop
• after executing files on specified archive, there should be a LICENSE file in the directory.
• [... other stuff that I can't think about right now...]

The problem is: We already have some validation in cmd/validate-krew-manifest tool that is run only for krew-index. This validation:

1. runs all structural validation through Validate()
2. ensures: all spec.platforms[] items are used
3. ensures: no overlapping spec.platform[].selectors
4. ensures: all spec.platforms[] install fine

• point 1: Already validated by krew, during parsing
• point 2: Not a functional validation, if there's unused platforms[], krew continues to work fine.
• point 3: I believe Krew continues to work fine when there are overlapping selectors –though, the behavior is undefined (not sure which one would be picked up, as we don't guarantee it). We could move this to "functional validation", though I'm not sure we totally should.
• point 4: Not "structural validation", just ensures plugins merged to krew-index are installable, we can't enforce this in custom indexes.

So maybe we just make cmd/validate-krew-manifest more about "styling" and make it clear it's meant for krew-index.

/kind proposal /cc @corneliusweig

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community. /close

hey krew-index team,

I am krew-release-bot, and I would like to open this PR to publish version v0.19.0 of reliably on behalf of @reliably-ci.

Thanks, @krew-release-bot

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: <a href="https://github.com/kubernetes-sigs/krew-index/pull/1350#issuecomment-866909701" title="Approved">ahmetb</a>, <a href="https://github.com/kubernetes-sigs/krew-index/pull/1350#" title="Author self-approved">krew-release-bot</a>

The full list of commands accepted by this bot can be found here.

The pull request process is described here

<details > Needs approval from an approver in each of these files:

• OWNERS [ahmetb]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment </details> <!-- META={"approvers":[]} -->

hey krew-index team,

I am krew-release-bot, and I would like to open this PR to publish version v0.19.0 of reliably on behalf of @reliably-ci.

Thanks, @krew-release-bot

I'm curious that why memory are kept when Idle

Thank you for this awesome resource. I believe the default value for concurrency is out of date - the referenced doc state "By default each Cloud Run container instance can receive up to 80 requests at the same time..."

Thanks!