-
Notifications
You must be signed in to change notification settings - Fork 52
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
Add link to chocolatey for WIndows install #74
base: develop
Are you sure you want to change the base?
Conversation
In addition to brew, add the easy windows way of installer
Hey @adriens, thanks for the PR! When navigating to that link, it looks like vendir has been flagged as potentially unsafe by some scanners. Is that something that needs to be resolved? |
Hi, yes, I saw that. I did not want to bother with that. In fact it has a very low risk score (the lower the better) : It seems according to the report that |
To check that more acuratley, can you do the same operation as me :
Here is what I got : https://www.virustotal.com/gui/file/c2767e0a5891d10a49b9b21a6dafd23fe1e47dde8be01ff91612ab4a956f8329/detection can you reproduce that ❔ |
I can try out these steps tomorrow to see if I can reproduce. Aside from that, we were wondering if you would like to contribute the chocolatey repos for carvel tools to the vmware-tanzu github org. Before adding these links both here and in the ytt PR, we would like to provide a stronger guarantee around maintenance of the repos, and having them part of vmware-tanzu would allow us to do that in the event you decide you no longer want to maintain them. It would also help with the discoverability of the repos by having them in the same github org as all other carvel related repos. If you are willing to contribute them, you would be added as the maintainer of the repo, similar to how the setup-carvel-action is configured. We'd really appreciate the contribution, so let us know what you think! |
Hi @ewrenn8 , thanks a lot for your very kind feedback... looks like this conribution channel is going one step further 😃 .
Sure, for now the process is manual (not GH Action nor CI driven). So, if I understand it properly :
What do you thing about that plan ? I could launch it on the next release.
Totally legit, and strongly agree with you 👍
Yep, also totally makes sense👍
Yep, and I would applu this on each of the tools ( How do you feel about my feedback ❔ 😸 |
That all sounds great! There are a few things we will have to take care of on our end before migrating the repos, so we will get started on that right away. I am not sure how long it will take, but hopefully not too long. I will let you know when everything is all set! |
Hey @adriens is there any reason the chocolatey packages for each tool need to be in their own repos? Looking at some other chocolatey repos, it seems like there can be multiple packages within the same repo. If we were to add a single repo for all the carvel chocolatey packages, could the existing package repos be consolidated there? |
Multiple Chocolatey packages should all be able to exist under a single GitHub repository. The main artifact produced is the nupkg, which can be generated within subfolders (each tool could have its own subfolder) of the main repo. I also don’t think there should be any issues migrating several repositories into one. |
Great! Does combining those repos in to a single |
Hi @ewrenn8 , sorry for late answer, this week is pretty charged.
I did had this approach (one choco repo by tool) as I like to get a repos for each purpose, to keep things easier to manage or delegate. In fact it seems like there are two options :
Initially, I wanted to keep a repo by tool so the code is simpler and tag management easier as at the end the CI should do the job. BTW, do you think it may be possible, on each source code repo, to releaase windows binary also as a zip file ?... attached to the release artefacts ? |
+1 This is related to a draft PR i have in imgpkg (and intend on porting over to ytt, kapp and kbld) to also upload assets as zip files to assist in automating updates to homebrew. |
@ewrenn8 , just updated adriens/chocolatey-vendir#10 to prepare repo ownership transfer, that will take place just after adriens/chocolatey-vendir#9 is closed (hopefully this week) |
Great, thanks for capturing that! We've had quite a bit going on the last week, so we still have some things we would like to figure out before moving it over, sorry. I don't think we will be able to make much progress until next week sometime, is that ok? For transparency, we are thinking about how we would like to structure the interaction between our CI, a new release, and the location of the chocolatey repo. We have a few options which we are thinking about:
|
Hi @ewrenn8 , no worry, i also had a rough week so I just even could not find time to reply on the issue. Clearly, the first option
Is the most elegant one, by far. And having close to the target software makes the process smooth and efficient. I've automated the
So it can give you some inspiration on how it could be done in the future. 👉 For now I did with |
Hey @adriens we had a quick sync on this today, and we think we may actually go with the single chocolatey repo option. Since we are already setting up the same type of automation that would be required for that option for the Homebrew repository, it should be a pretty straightforward expansion to add updating the chocolatey repo on a release. Also, having a single repo with commit shas and history is also desirable from an auditability standpoint, as using templates inlined in github actions could lose useful history. Lastly, it will allow us to scope permissions better, since we would definitely like you to be added as a maintainer of the chocolatey repo. The current thinking is:
How does this sound to you? |
Hi @ewrenn8
that sounds pretty good to me. 👍
Yep, shall I make you the PR or will you make them by your own ? I could fill isssue for each of them to keep work organized and link PR to issues (I like pretty much working like that)
👌
Looks good to me. Now, question for you 😃 : will a zip version of the windows
Additional considerationsOnce all these tasks will be achieved, we'll have to think about how to share the CHOCO_API_KEY, if you're ok wth using Appveyor, etc... 😸 |
💡 On |
@ewrenn8 , I've implemented the CI release see https://github.com/adriens/chocolatey-imgpkg/blob/main/README.md 👉 New release processNow, the Chocolatey release process is as simple as :
Now, wait for Chocolatey.org to release the package 😎. As you can see it's quite straightforward. 😄 ❔ QuestionFor now, I don't exactly have the idea of how I'll port this to a repo where all projects are stored on dedicated directories. Shall I switch to a branch model (one by tool) ? In other words, how to trigger the proper action when a release has been created ? |
In addition to brew, add the easy windows way of installer