Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing supply chain security features to the Go community

github.blog

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Bringing supply chain security features to the Go community

#61

Post by plasma »

jacobparker wrote: post #35
plasma wrote: post #15

Earlier quoted context omitted.

HN is great, can I chime in with some feedback too, for NuGet I’m seeing Dependabot open separate PRs for the same dependency that’s out of date in the one repo that has multiple projects that relate to each other (they reference one another in csproj files). They thus also need to be updated together, but I wish one PR was opened to update the dependencies in all projects at once, instead of multiple PRs I to merge.…

For NuGet, consider using centralized package references: https://github.com/NuGet/Home/wiki/Centrally-managing-NuGet-... You get one file defining the set of all packages used in your repo (or some subset of your repo, etc.) and Dependabot will update this file directly. Individual projects can choose to use a package but won't specify the version. It requires that your projects are all in sync with package versions…

Thank you, looks like it’s still on preview but glad it’s being worked on.

Re: Bringing supply chain security features to the Go community

#62

Post by plasma »

greysteil wrote: post #20
plasma wrote: post #15

Earlier quoted context omitted.

HN is great, can I chime in with some feedback too, for NuGet I’m seeing Dependabot open separate PRs for the same dependency that’s out of date in the one repo that has multiple projects that relate to each other (they reference one another in csproj files). They thus also need to be updated together, but I wish one PR was opened to update the dependencies in all projects at once, instead of multiple PRs I to merge.…

Feature requests always welcome! I'll pass it on to the Dependabot team.

Thank you

Re: Bringing supply chain security features to the Go community

#63

Post by pabs3 »

leo_bloom wrote: post #2

GitHub's dependabot is causing a ton of "spam" in our frontend (Angular) repositories, as it seemingly opens 1-5 PRs per day to bump random dependencies. I really hope this does not become common practice for our Go repositories. Is there an option to tell dependabot "make one PR per week at most, please, and bundle your changes"?

Not recording exact dependency versions seems like the right way to stop those PRs from happening.

Re: Bringing supply chain security features to the Go community

#64

Post by starefossen »

dmitriid wrote: post #54
starefossen wrote: post #5

Earlier quoted context omitted.

The amount of pull requests from dependency updates can become more manageable if you enable GitHub’s Auto Merge feature[1] [1] https://docs.github.com/en/github/collaborating-with-pull-re...

You can't enable granular auto merges: I'm fine with auto merging minor/security update PRs from dependabot. Not anything else. You can't set up that.

You could probably use a GitHub Action and check the API for author of the pull request if you want to require additional verification. If have done something similar with auto accepting docs-only pull requests in the past.

Re: Bringing supply chain security features to the Go community

#65

Post by asciimike »

leo_bloom wrote: post #2

GitHub's dependabot is causing a ton of "spam" in our frontend (Angular) repositories, as it seemingly opens 1-5 PRs per day to bump random dependencies. I really hope this does not become common practice for our Go repositories. Is there an option to tell dependabot "make one PR per week at most, please, and bundle your changes"?

Dependabot PM following up a few days late

> Is there an option to tell dependabot "make one PR per week at most ...

You can set the `open-pull-requests-limit: 1` (https://docs.github.com/en/code-security/supply-chain-securi...) and the `schedule.interval: weekly` to limit the number of created PRs to one per week

> ... and bundle your changes"?

We've referred to this feature as "grouped updates" and it's tracked on the roadmap: https://github.com/github/roadmap/issues/148

Potentially using `allow: direct` (https://docs.github.com/en/code-security/supply-chain-securi...) to ignore the random sub dependencies, or ignoring minor versions (https://docs.github.com/en/code-security/supply-chain-securi...) of some/all dependencies might help reduce that noise.

Re: Bringing supply chain security features to the Go community

#66

Post by asciimike »

plasma wrote: post #62
greysteil wrote: post #20

Earlier quoted context omitted.

Feature requests always welcome! I'll pass it on to the Dependabot team.

Thank you

Let me know if https://github.com/github/roadmap/issues/148 is in the right spirit of what you're aiming for.

I think that what will get implemented will be a bit broader (covering version updates and security updates) and will allow for grouping by manifest, language, vulnerability, and potentially arbitrary labeling in the config file.

Re: Bringing supply chain security features to the Go community

#67

Post by asciimike »

newman314 wrote: post #44
greysteil wrote: post #13

Earlier quoted context omitted.

PM for security products at GitHub here (and one of the original authors of Dependabot). Sorry to hear that. I wouldn't expect us to be telling you about 1-5 security issues a day - do you maybe have (non-security) version updates enabled? If so and they feel like spam to you I'd recommend turning them off. (I wish I had a better suggestion, but until Dependabot supports grouped updates it sounds like it just isn't r…

While we are on the feedback train, please consider making the Docker dependabot action more intelligent. Right now, I have a monorepo with multiple Dockerfiles in subdirectories. I end up having to add an entire docker block scoped to each directory that has a Dockerfile which is painful. Ideally, I would have a way to specify using */Dockerfile as a way to scan for Docker dependencies. Also, multi-stage Dockerfile…

> I end up having to add an entire docker block scoped to each directory that has a Dockerfile which is painful. Ideally, I would have a way to specify using */Dockerfile as a way to scan for Docker dependencies.

Glob syntax in `directory` would be sufficient, yes?

Re: Bringing supply chain security features to the Go community

#68

Post by asciimike »

starefossen wrote: post #64
dmitriid wrote: post #54

Earlier quoted context omitted.

You can't enable granular auto merges: I'm fine with auto merging minor/security update PRs from dependabot. Not anything else. You can't set up that.

You could probably use a GitHub Action and check the API for author of the pull request if you want to require additional verification. If have done something similar with auto accepting docs-only pull requests in the past.

Dependabot PM here:

We've provided an action that will provide metadata (e.g. semver bump) that you can use to enable granular automerge. See https://github.com/dependabot/fetch-metadata/#enabling-auto-... for an example.

Re: Bringing supply chain security features to the Go community

#69

Post by newman314 »

asciimike wrote: post #67
newman314 wrote: post #44

Earlier quoted context omitted.

While we are on the feedback train, please consider making the Docker dependabot action more intelligent. Right now, I have a monorepo with multiple Dockerfiles in subdirectories. I end up having to add an entire docker block scoped to each directory that has a Dockerfile which is painful. Ideally, I would have a way to specify using */Dockerfile as a way to scan for Docker dependencies. Also, multi-stage Dockerfile…

> I end up having to add an entire docker block scoped to each directory that has a Dockerfile which is painful. Ideally, I would have a way to specify using */Dockerfile as a way to scan for Docker dependencies. Glob syntax in `directory` would be sufficient, yes?

It's unclear if you are saying if that already works but yes that would be sufficient. =D

Re: Bringing supply chain security features to the Go community

#70

Post by asciimike »

newman314 wrote: post #69
asciimike wrote: post #67

Earlier quoted context omitted.

> I end up having to add an entire docker block scoped to each directory that has a Dockerfile which is painful. Ideally, I would have a way to specify using */Dockerfile as a way to scan for Docker dependencies. Glob syntax in `directory` would be sufficient, yes?

It's unclear if you are saying if that already works but yes that would be sufficient. =D

It doesn't, and was meant as a question
Post reply on HN