Call for code reviewers!

[canterberry]

As of right now, we've got about 8 open PRs. Let's those reviewed and approved+merged or closed! If you're one of those contributors, thank you for your patience and for your work.

I'm not an active user of this chart, myself, but if you're reading this, then you probably are. I need more folks like you to help review PRs. There's changesets more ambitious than I'm personally comfortable with reviewing on my own, but if they're to benefit the community, they need 👀.

If you're interested, please go right ahead and review some PRs!

There aren't currently any formal contribution guidelines [yet] for this repo, so I'll just outline the one I think is of utmost importance:

Whether you're a PR author or a reviewer, show respect and gratitude for one another. Move forward in good faith. All opinions and voices are welcome here. That said, please be willing to give and receive criticism from time to time, and do so in a kind, respectful, and gracious manner.

[joshsizer]

@canterberry I'd be happy to become a reviewer

[vyas-n]

I'd be up for being a reviewer/contributor.

I mostly work on CI pipelines for my day job, if you don't mind, I can create CI pipelines here to validate PRs before merging.

[canterberry]

I'ved added you both to the project with Maintainer permissions. Thanks for volunteering! You're welcome to contribute in any way you're comfortable, as little or as much as you'd like.

I'll keep an eye open to see how things are going and if there's anything you need from me.

[joshsizer]

@vyas-n @canterberry What does the release process look like?

From what I can tell we just need to add a chart tar to the gh-pages branch, but it looks like the tar is signed with a pgp key?

ee65244

I'm not familiar with this signing process, if we need a special private pgp key, etc?

[vyas-n]

Looks like the CI process is currently failing:

I don't have access to the Circle CI Org, but I'll create a PR to move the logic from Circle CI over to GitHub Actions.

[canterberry]

@vyas-n @canterberry What does the release process look like?

From what I can tell we just need to add a chart tar to the gh-pages branch, but it looks like the tar is signed with a pgp key?

ee65244

I'm not familiar with this signing process, if we need a special private pgp key, etc?

Yes, the gh-pages branch is probably the best spot for releases. I still own and operate the repo at https://helm.twun.io/ , but with GitHub Pages, I'm personally removed as a dependency/bottleneck and the release process can be more easily delegated and collectively governed.

Here's the issue/comment where the gh-pages branch release strategy started: #22 (comment)

Here's how release signing works: https://helm.sh/docs/topics/provenance/

I recommend generating your own designated release signing key for this repo and publishing that public key here somewhere, so folks know who the key belongs to and that the signature belongs to an authorized releaser.

📝 I'll defer to y'all on whether to sign releases at all -- I'm not sure how important provenance is for most people. I get the sense that it's a less commonly used feature.

This looks like it could be a decent starting point for a CI-automated release process: https://helm.sh/docs/howto/chart_releaser_action/

[joshsizer]

@canterberry @vyas-n I was thinking about using GitHub pages for the releases, but I'm worried that if we change the registry url, we'll lose a lot of community traction.

For example, Linode has this chart as their recommended way to install a docker registry: https://www.linode.com/docs/guides/how-to-setup-a-private-docker-registry-with-lke-and-object-storage/#:~:text=deploy%20your%20docker%20registry%20using%20the%20configurations

helm repo add twuni https://helm.twun.io

I was wondering if there was any good solutions to keep using helm.twun.io, but still delegate releases?

[canterberry]

@joshsizer

I was wondering if there was any good solutions to keep using helm.twun.io, but still delegate releases?

Two options come to mind:

• Set up a permanent redirect from https://helm.twun.io to https://twuni.github.io/docker-registry.helm using HTTP 301 response status with an appropriate Location header. If Helm's tooling follows redirects, this should work just fine.

• Set https://helm.twun.io as a passthrough proxy for https://twuni.github.io/docker-registry.helm. This change would be completely transparent to Helm tooling, but I would need to enforce an exception for paths with the prefix /.well-known/ in order to guard against certificate hijacking and other related attacks involving HTTP-based domain validation.

I'm inclined toward the second option. Either way, the result would be to manage releases via GitHub Pages and to distribute releases via both GitHub Pages and helm.twun.io.

I'll get started on this now and report back when it's ready.

[canterberry]

Quick update:

I ran a pilot of the second option above on a separate, temporary domain, with success. I'm working on the next step now, applying that to https://helm.twun.io. In the meantime, the Helm repo will be temporarily unavailable. ETA on completing this work is another 15-20 minutes.

[canterberry]

@joshsizer This work is now complete.

https://helm.twun.io is now a passthrough proxy for https://twuni.github.io/docker-registry.helm and can be updated via the gh-pages branch.