search

paketo-buildpacks / jammy-tiny-stack

Tiny (minimal) stack for Ubuntu 2022.04: Jammy Jellyfish
Apache License 2.0
5 stars 10 forks source link

Update out of date dependencies #139

Open candrews opened 1 year ago

candrews commented 1 year ago

Describe the Enhancement

There are many dependencies that are out of date in https://github.com/paketo-buildpacks/jammy-tiny-stack/blob/main/go.mod

Can those dependencies please be updated?

Possible Solution

Update dependency versions in go.mod.

Perhaps a tool such as dependabot or Renovate should be enabled so this project becomes aware of updates as they become available.

Motivation

For example, github.com/paketo-buildpacks/jam is out of date. It would be nice to update it to 2.4.0 (or later) so that the /home/cnb directory gets file mode set to 0750 (per https://github.com/paketo-buildpacks/jam/commit/a25549483faf6293a80d6dbb0fba2132d9685c0e). This would resolve https://github.com/paketo-buildpacks/jammy-tiny-stack/issues/130

I suspect there are many other benefits that would be realized by updating other dependencies.

robdimsdale commented 1 year ago

All of those dependencies are only for tests. Even jam. The version of jam used to build the stack is found here.

Looking at the history of that file, we're already building stacks with jam v2.4.0 (and have been since this commit, roughly three weeks ago).

I don't really feel strongly about keeping test dependencies up to date. I recognize it's confusing that we use jam as a library for its test matchers, and I think it might be more clear to remove that dependency in favor of our testing library occam.

If we had already done this test refactor, I suspect you wouldn't be opening this issue, because you wouldn't have seen jam in the go.mod and assumed that this was the version of jam used to build the stack. Or, at least, you might be opening an issue asking when the next version of the stack will be built using jam v2.4.0 😄

If we do decide to add dependabot - for test dependencies only - then we would add it to the shared github config, here. That will propagate out to all the stack repositories, including this one.

candrews commented 1 year ago

Thank you for your detailed and informative answer, I greatly appreciate it.

I don't really feel strongly about keeping test dependencies up to date. I recognize it's confusing that we use jam as a library for its test matchers, and I think it might be more clear to remove that dependency in favor of our testing library occam.

If we had already done this test refactor, I suspect you wouldn't be opening this issue, because you wouldn't have seen jam in the go.mod and assumed that this was the version of jam used to build the stack. Or, at least, you might be opening an issue asking when the next version of the stack will be built using jam v2.4.0 😄

I agree, and I think that would be a really nice improvement.

I don't really feel strongly about keeping test dependencies up to date.

If we do decide to add dependabot - for test dependencies only - then we would add it to the shared github config, here. That will propagate out to all the stack repositories, including this one.

IMHO, it's a good idea to keep all dependencies, including test dependencies, up to date. I think adding dependabot as described would be really great.

robdimsdale commented 1 year ago

IMHO, it's a good idea to keep all dependencies, including test dependencies, up to date. I think adding dependabot as described would be really great.

I do generally like the idea of keeping everything up to date. It's also simpler than having debates about what is updated and what isn't, and why. But I also want to make the point that test dependencies (should) have no impact on production vulnerabilities. That's obvious but i think it can be easy to overlook when having conversations about keeping everything up to date.

Feel free to open a PR to the shared config. I'd probably model it on other examples (e.g. the implementation buildpacks). If you don't get to this, we'll probably get around to it at some point.