Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative branching for custom indexes instead default branch #832

Closed
ardaguclu opened this issue Aug 10, 2023 · 5 comments
Closed

Alternative branching for custom indexes instead default branch #832

ardaguclu opened this issue Aug 10, 2023 · 5 comments

Comments

@ardaguclu
Copy link

Currently, when user adds a custom index, Krew clones this repository from the default branch statically. Since distributions of most of plugins are managed in these default branches(master, main, etc.), it works without problem.

On the other hand, this mechanism does not work for the plugins that using branching strategy per release. For a specific cluster version, plugin maintainers want to force users to use only specific major version(and auto updates of minor versions via Krew). For example, for my cluster v1.2.X, user should use 1.2.X which means that user should add Krew custom index only being encompassed by this branch and I'll continue working on master branch for the next release cycle, v2.0.X without impacting v1.2.X releases.

This feature proposal may look very specific, but this provides an option to plugin maintainers about just cutting a branch for a specific release and continue working on new features on their master. And old clients can still use it safely because auto upgrade will not upgrade to a very latest version which is apparently not compatible.

As maintainers of Krew, you know the use cases and features requests better than me and if my proposal still looks very exception, feel free to close this issue.

/kind proposal

@ardaguclu
Copy link
Author

I added a solution with respect to my proposal #833. Appending branch name with # will set the cloned repositories default branch to the given one. It worked without any problem in my tests.

@chriskim06
Copy link
Member

it seems a little strange to me to handle this with different versions of the index. homebrew handles this by allowing versioned formulae in their main tap. i dont know off the top of my head if that is already possible with krew (i forget exactly what parts of the plugin spec are used to setup the binary installed in .krew/store and the symlink in .krew/bin). there are other things in addition to having separate plugins that would be needed though, like how to link a specific version.

i think your implementation makes sense for solving this by versioning the index (as long as that clone command properly sets refs/remotes/origin/{branch} so that the git reset --hard @{upstream} is referencing the correct remote), but im not totally convinced it should be handled there instead of supporting different plugin versions.

@ardaguclu
Copy link
Author

it seems a little strange to me to handle this with different versions of the index. homebrew handles this by allowing versioned formulae in their main tap. i dont know off the top of my head if that is already possible with krew (i forget exactly what parts of the plugin spec are used to setup the binary installed in .krew/store and the symlink in .krew/bin). there are other things in addition to having separate plugins that would be needed though, like how to link a specific version.

i think your implementation makes sense for solving this by versioning the index (as long as that clone command properly sets refs/remotes/origin/{branch} so that the git reset --hard @{upstream} is referencing the correct remote), but im not totally convinced it should be handled there instead of supporting different plugin versions.

@chriskim06 thanks for your comments. I had a similar discussion on Slack with @ahmetb and he also had some concerns about supporting this in terms of maintainability and narrow audience.

I'm closing my PR due to this, I'll keep issue for a while in case someone else also need this;
/close

@ardaguclu
Copy link
Author

I incorrectly closed issue :). Sorry for noise.

@ardaguclu ardaguclu reopened this Aug 11, 2023
@ardaguclu
Copy link
Author

/close

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants