Add support for helm files.

[brendandburns]

This PR extends the recent Kubernetes support for Docker containers to common Helm chart formats:

foo:
  image:
    repository: sql/sql
    tag: 1.2.3
    registry: docker.io

or alternatively:

foo:
  image:
    repository: sql/sql
    version: 1.2.3

[honeyankit]

@brendandburns : The docker CI / CI (docker, docker) (pull_request) build failed. There are few failures due to the naming convention of the method and variable names (Naming/MethodName:). Request you to fix that. Thank you.

[brendandburns]

@honeyankit thanks I'll take a look. (is there a way that I can run these locally?)

[brendandburns]

@honeyankit style issues addressed (I hope) ptal

[jeffwidman]

is there a way that I can run these locally?

https://github.com/dependabot/dependabot-core#running-the-tests describes how to run the Rubocop style checks. I highly suggest running those commands within the docker container as described in the section just above that one.

[brendandburns]

Rebased.

[brendandburns]

@honeyankit this seems to be failing because of a permission problem unrelated to this PR.

If it is something in this PR please let me know and I will try to fix it.

[mattt]

@honeyankit this seems to be failing because of a permission problem unrelated to this PR.

If it is something in this PR please let me know and I will try to fix it.

Sorry for the confusion there. That's not a required check, so it's not a blocker for merging.

The workflow in question pushes images built for PRs to GitHub Container Registry, so that we can easily deploy changes before merging. This step currently fails on PRs from forks, because forks won't have write access to GHCR (see #5668). This is a known issue and we're working on a solution.

(Also, thanks for your contribution! I'm really excited to add support in Dependabot for Helm charts)

[jeffwidman]

Also, can you please squash the lint change commit into the original commit?

We currently can't merge via squash due to a limitation in our release script so whatever the commit history is on this branch is what makes it into main...

[brendandburns]

Comments addressed, commits squashed and rebased.

Please take another look.

Thanks!

[brendandburns]

Comment addressed. Please take another look.

[brendandburns]

@jeffwidman

newlines added. fwiw, the JSON formatter for VS Code/Codespaces removes the newline at the end of JSON files, so I'm not sure that newlines for JSON is standard, but nonetheless they should be there now.

Please take another look.

Thanks!

[jeffwidman]

fwiw, the JSON formatter for VS Code/Codespaces removes the newline at the end of JSON files, so I'm not sure that newlines for JSON is standard, but nonetheless they should be there now.

Oh interesting. I'm surprised by that, I'll have to research that a bit more.

[jeffwidman]

Hmm... something wrong here, I clicked the Update via Rebase and now it says:

dependabot-ci authored and jeffwidman committed 1 minute ago

Hmm... I'm going to amend the commit to ensure Brendan is the author here.

[jeffwidman]

That looks better, @brendandburns see ☝️ I have no idea what went wrong, something in GitHub's Update with Rebase command... Anyway, I wasn't sure what email you preferred to use, and there was no history due to the force push so I used your @microsoft.com email, as that's what it looks like you used elsewhere on other commits on your profile.

I'll deploy this once CI goes green, and assuming everything looks good in production will merge this later tonight.

[brendandburns]

@jeffwidman Thanks and yes, the @microsoft.com address is generally what I use.

Great to see this merge!

[nilekhc]

That looks better, @brendandburns see ☝️ I have no idea what went wrong, something in GitHub's Update with Rebase command... Anyway, I wasn't sure what email you preferred to use, and there was no history due to the force push so I used your @microsoft.com email, as that's what it looks like you used elsewhere on other commits on your profile.

I'll deploy this once CI goes green, and assuming everything looks good in production will merge this later tonight.

Hi @jeffwidman, Do we need to cut a new tag to use this feature?

[jeffwidman]

It is already deployed to GitHub prod, but requires a feature flag. If you are using it somewhere other than GitHub than you'll need to use mainas not yet on a tagged release.

[nilekhc]

It is already deployed to GitHub prod, but requires a feature flag. If you are using it somewhere other than GitHub than you'll need to use mainas not yet on a tagged release.

I am using it outside of GH. When it'll be available on tagged release?

[nilekhc]

@jeffwidman Any timeline on when the tag release will cut?

[jurre]

I am using it outside of GH. When it'll be available on tagged release?

We don't really do tagged releases anymore as our deployment model has changed a bit and we don't need them anymore, you can just pull the changes in from a sha

[nilekhc]

cc @mburumaxwell

[jeffwidman]

Long term, I think we probably should still make tagged releases available on RubyGems to make life easier for those who run Dependabot in custom ways.

But since we are now deploying multiple times a day straight from PR branches before they merge back to main we'll probably move away from manually running the release scripts that push to RubyGems and instead automate it to cut versions on a monthly or weekly basis. This also means we'll likely need to move away from semver guarantees.

That said the above is my personal opinion and others on the team may feel differently... So just overall there's some planning / internal discussion that needs to happen and no one has had the bandwidth to drive that yet.. I'm hopeful I might have time before end of quarter but I can't guarantee it.

[jeffwidman]

Currently this is buried behind a feature flag for folks on GitHub.com...

We'd like to start slowly rolling it out for everyone, but before I do that, I'd like to test on a few repos to ensure no unexpected issues. I can / will setup a fake test repo, but there's nothing like live data to confirm things.

Anyone watching this PR care to volunteer to have their repo(s) be part of the beta test?

Repos must match the following criteria:

• on GitHub.com
• public, because for security reasons we can't access private repos w/o jumping through some hoops
• have helm files... ideally with a combination of up-to-date and outdated docker image tags

If interested, please comment on this thread with the URLs of any repos you own/maintain.

[jeffwidman]

@nilekhc This is now live on RubyGems: https://rubygems.org/gems/dependabot-omnibus/versions/0.213.0

[nilekhc]

Currently this is buried behind a feature flag for folks on GitHub.com...

We'd like to start slowly rolling it out for everyone, but before I do that, I'd like to test on a few repos to ensure no unexpected issues. I can / will setup a fake test repo, but there's nothing like live data to confirm things.

Anyone watching this PR care to volunteer to have their repo(s) be part of the beta test?

Repos must match the following criteria:

• on GitHub.com
• public, because for security reasons we can't access private repos w/o jumping through some hoops
• have helm files... ideally with a combination of up-to-date and outdated docker image tags

If interested, please comment on this thread with the URLs of any repos you own/maintain.

Hey @jeffwidman, we can test with our repo if you are still looking for volunteers. https://github.com/Azure/secrets-store-csi-driver-provider-azure

Let me know what I need to do.

cc @aramase

[jeffwidman]

Awesome thanks @nilekhc

I will enable the feature flag on your repo tomorrow, and then since it's a public repo I think I can internally trigger a dry-run to test it. I'll post a follow-up once the flag is enabled.

[jeffwidman]

Also @nilekhc you'll need to enable a "docker" ecosystem check in https://github.com/Azure/secrets-store-csi-driver-provider-azure/blob/master/.github/dependabot.yml for the whatever folder holds these files. IIRC, the check will recursively search for files, so if you've got nested subdirs of charts, targeting the "docker" check at the parent dir should be fine.

[nilekhc]

Also @nilekhc you'll need to enable a "docker" ecosystem check in https://github.com/Azure/secrets-store-csi-driver-provider-azure/blob/master/.github/dependabot.yml for the whatever folder holds these files. IIRC, the check will recursively search for files, so if you've got nested subdirs of charts, targeting the "docker" check at the parent dir should be fine.

PR - https://github.com/Azure/secrets-store-csi-driver-provider-azure/pull/1014

[nilekhc]

@jeffwidman It's working on our repo - https://github.com/Azure/secrets-store-csi-driver-provider-azure/pulls

[jeffwidman]

Awesome news thanks for circling back!