Add link to chocolatey for WIndows install

[adriens]

In addition to brew, add the easy windows way of installer

[ewrenn8]

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?

[adriens]

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

[adriens]

To check that more acuratley, can you do the same operation as me :

1. Drop original vendir binary on virustotal
2. Get the report

Here is what I got :

https://www.virustotal.com/gui/file/c2767e0a5891d10a49b9b21a6dafd23fe1e47dde8be01ff91612ab4a956f8329/detection

can you reproduce that ❔

[ewrenn8]

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!

[adriens]

Hi @ewrenn8 , thanks a lot for your very kind feedback... looks like this conribution channel is going one step further 😃 .

Aside from that, we were wondering if you would like to contribute the chocolatey repos for carvel tools to the vmware-tanzu github org

Sure, for now the process is manual (not GH Action nor CI driven). So, if I understand it properly :

1. I would transfer the repo
2. I would go on to maintain them (you would let me push on it)
3. I could ask you to provide me some binaries an another way so the choco download would target your release assets (that would much much clean).
4. I could implement it on a CI so the upgrade process may only need to modify a property file (which actually not the case)

What do you thing about that plan ? I could launch it on the next release.

we would like to provide a stronger guarantee

Totally legit, and strongly agree with you 👍

It would also help with the discoverability of the repos by having them in the same github org as all other carvel related repos.

Yep, also totally makes sense👍

If you are willing to contribute them, you would be added as the maintainer of the repo

Yep, and I would applu this on each of the tools (ytt, vendir, imgpkg, ...). Starting on the next release on of of them.

How do you feel about my feedback ❔ 😸

[ewrenn8]

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!

[ewrenn8]

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?

[danielhelfand]

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.

[ewrenn8]

Great! Does combining those repos in to a single carvel-chocolatey-packages repo sound good to you @adriens?

[adriens]

Hi @ewrenn8 , sorry for late answer, this week is pretty charged.

I also don’t think there should be any issues migrating several repositories into one.

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 :

• embed the nupk release process as part of each tool repo (looks very elegant to me), through GH Action
• create a dedicated repo that plays with directories (one by tool I may say), and build choco packages by referencing artifacts released on each tool, but with this approach, we should create a fake "carvel-tool meta version" that comes on top of ytt, vendir, imgpkg tools

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 ?

[DennisDenuto]

on each source code repo, to releaase windows binary also as a zip file

+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.

carvel-dev/imgpkg#180

[adriens]

@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)

[ewrenn8]

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:

1. Template the chocolatey definition and add it a workflow. Whenever a new release is cut, the action will trigger and provide the release version and link to the templates and publish the final result to the chocolatey website. I believe this is along the lines of what you suggested earlier
2. Have a dedicated repo for the chocolatey definitions. We would then need to find a way to either update that repo when a new release of a tool is cut, or somehow trigger an action in that repo on a release of a tool
3. Keep all the chocolatey repos separate and leave the process as is. This is definitely the least desirable as it is entirely manual

[adriens]

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

Template the chocolatey definition and add it a workflow. Whenever a new release is cut, the action will trigger and provide the release version and link to the templates and publish the final result to the chocolatey website. I believe this is along the lines of what you suggested earlier

Is the most elegant one, by far. And having close to the target software makes the process smooth and efficient. I've automated the ytt chocolatey repo so everything is done through CI. The only thing to do is to :

1. update ytt.properties with ytt.version=0.35.0
2. create a release on the Gh repo
3. let the Appveyor CI do the job :

So it can give you some inspiration on how it could be done in the future.

👉 For now I did with ant and and AppVeyor as I'm comfortable with these tools, but the wholle thing can be done on GH Actions thanks to the choco action. Since now, I'm able to release faster and also document the release process.

[ewrenn8]

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:

1. We create a repository in vmware-tanzu called carvel-chocolatey-packages
2. The separate chocolatey repos you're maintaining now are pull requested in (this helps us for legal reasons relating to the CLA)
3. You will be added to the repository as a maintainer
4. We will add or accept contributions adding automation to the specific tooling repos that will trigger on release and commit and push an update to the chocolatey repo.

How does this sound to you?

[adriens]

Hi @ewrenn8

We create a repository in vmware-tanzu called carvel-chocolatey-packages

that sounds pretty good to me. 👍

The separate chocolatey repos you're maintaining now are pull requested in (this helps us for legal reasons relating to the CLA)

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)

You will be added to the repository as a maintainer

👌

We will add or accept contributions adding automation to the specific tooling repos that will trigger on release and commit and push an update to the chocolatey repo.

Looks good to me.

Now, question for you 😃 : will a zip version of the windows exe be available a each tool asset ? I could :

• make cleaner choco packages (vs. actually embedding exe files)
• make release process much much smoother
• keep download stats more acurate (actually, the choco install does not download from GH repo.. hence making download stats inaccurate)
• make choco release process and no manual review will be required. Actually, even automated review process is slow, but addind custom embedded binaries sloww the package review even a bit slower, see details below

Additional considerations

Once 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... 😸

[adriens]

💡 On carvel-chocolatey-packages, I may also create a project to keep actions visible and on track💡

[adriens]

@ewrenn8 , I've implemented the CI release see https://github.com/adriens/chocolatey-imgpkg/blob/main/README.md

👉 New release process

Now, the Chocolatey release process is as simple as :

1. Update the target version in imgpkg.properties
2. Wait for AppVeyor CI validation
3. Create a GH Release

Now, wait for Chocolatey.org to release the package 😎.

As you can see it's quite straightforward. 😄

❔ Question

For 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 ?