Closed grosser closed 6 months ago
-manifest-url/-manifest-file is largely intended for testing manifests; not for distribution. You can still ship an executable to your colleagues and they can put it on their PATH?
We could change the scope and behavior here but I suspect it won't be a major UX improvement for a broad audience.
If it's intended for testing then allowing not using a Sha would make that even easier ?
On Tue, Dec 26, 2023, 6:11 PM Ahmet Alp Balkan @.***> wrote:
-manifest-url/-manifest-file is largely intended for testing manifests; not for distribution. You can still ship an executable to your colleagues and they can put it on their PATH?
We could change the scope and behavior here but I suspect it won't be a major UX improvement for a broad audience.
— Reply to this email directly, view it on GitHub https://github.com/kubernetes-sigs/krew/issues/846#issuecomment-1869881446, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACYZYDICD4MZQLQUVU6T3YLN7WTAVCNFSM6AAAAABBDYNU6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRZHA4DCNBUGY . You are receiving this because you authored the thread.Message ID: @.***>
It's used for testing the correctness of the manifest locally without sending a PR, so sha256 validation is part of that.
yeah, but allowing it to be missing could be nice if I want to test
everything else except the sha
also allows pointing to a generic latest.zip
On Tue, Dec 26, 2023 at 9:45 PM Ahmet Alp Balkan @.***> wrote:
It's used for testing the correctness of the manifest locally without sending a PR, so sha256 validation is part of that.
— Reply to this email directly, view it on GitHub https://github.com/kubernetes-sigs/krew/issues/846#issuecomment-1869970031, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAACYZ4FRM56CXANGNHTXETYLOYW3AVCNFSM6AAAAABBDYNU6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRZHE3TAMBTGE . You are receiving this because you authored the thread.Message ID: @.***>
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
I want to distribute my plugin to a few colleagues at first before getting it into krew-index. For that I want them to be able to just install from my manifest url which will point to the latest archive on github. Atm this breaks because I always have to add a sha, so I have to tag a release and then come back and get the sha and re-push the manifest.
I'd love either have:
Option A: no sha manifest, allow me toset
sha256: false
orsha256: 'insecure'
to opt-out Option B: No-sha install option: a--no-sha
or--ignore-sha
or--insecure
flag that others can use to have a simple 1-line installer without me having to keep the sha up to date.