search

runatlantis / atlantis

Terraform Pull Request Automation
https://www.runatlantis.io
Other
7.62k stars 1.03k forks source link

Remove old golang dependencies #2795

Open nitrocode opened 1 year ago

nitrocode commented 1 year ago

Community Note

Describe the user story

There are a lot of dependencies that may not be needed. Some dependencies are years old and could be vulnerable. The fewer dependencies, the less risk.

Describe the solution you'd like

It would be good to audit our dependencies and find ones that could be easily replaced or removed. We should use non forks if possible unless there is a good reason to use a fork.

It would also be good to scrutinize new PRs with additional dependencies to ensure we do not unnecessarily increase our exposure. For example, we should never use a dependency that is a fork or archived, possibly abandoned, not widely used, has old dependencies, or open security issues.

List of current dependencies https://github.com/runatlantis/atlantis/network/dependencies

Some old dependencies from a cursory look

Analyzing these will simplify dependent management via renovatebots dashboard https://github.com/runatlantis/atlantis/issues/2818

Direct

archived

archived no longer

old

For testing

These do not get compiled with Atlantis

Indirect

These come from other dependencies and need to be analyzed to find the direct source

https://stackoverflow.com/a/68927825/2965993

Some tools that may be useful

Here are all the go.mod code references sorted in ascending order

✗ grep -v indirect go.mod | grep -v ^module | grep github.com | awk '{ print $1 }' | sort | uniq | while read dep; do echo $(grep -r $dep **/*.go | wc -l):$dep; done | sort -n
1:github.com/Masterminds/sprig/v3
1:github.com/agext/levenshtein
1:github.com/alicebob/miniredis/v2
1:github.com/bradleyfalzon/ghinstallation/v2
1:github.com/briandowns/spinner
1:github.com/cactus/go-statsd-client/v5
1:github.com/go-test/deep
1:github.com/golang-jwt/jwt/v5
1:github.com/hashicorp/go-getter/v2
1:github.com/kr/pretty
1:github.com/microcosm-cc/bluemonday
1:github.com/mitchellh/colorstring
1:github.com/redis/go-redis/v9
1:github.com/remeh/sizedwaitgroup
1:github.com/spf13/pflag
1:github.com/warrensbox/terraform-switcher
2:github.com/google/shlex
2:github.com/hashicorp/terraform-config-inspect
2:github.com/mohae/deepcopy
2:github.com/shurcooL/githubv4
2:github.com/urfave/negroni/v3
3:github.com/gorilla/websocket
3:github.com/hashicorp/go-multierror
3:github.com/hashicorp/hcl/v2
3:github.com/moby/patternmatcher
3:github.com/spf13/viper
4:github.com/go-playground/validator/v10
4:github.com/mitchellh/go-homedir
5:github.com/google/uuid
5:github.com/spf13/cobra
6:github.com/slack-go/slack
7:github.com/gorilla/mux
13:github.com/mcdafydd/go-azuredevops
13:github.com/stretchr/testify
14:github.com/xanzy/go-gitlab
16:github.com/go-ozzo/ozzo-validation
23:github.com/uber-go/tally/v4
26:github.com/google/go-github/v53
53:github.com/pkg/errors
60:github.com/hashicorp/go-version
227:github.com/petergtz/pegomock/v3

Describe the drawbacks of your solution

Potential breakage of the app unless proper unit and integration test coverage is there.

Describe alternatives you've considered

None

chenrui333 commented 1 year ago

This is very nice!!

mitar commented 10 months ago

Shameless plug: as an alternative to https://github.com/pkg/errors, you can switch to drop-in replacement gitlab.com/tozd/go/errors. It fixes many issues, is maintained, and supports modern Go's error patterns (sentinel errors, %w formatting, joined errors, etc.). It also provides some nice utility functions and structured details so that it is easy to extract dynamic data out of errors (instead of trying to get them out of formatted strings). Has improved error formatting and JSON marshaling of errors. It is interoperable with other errors packages and does not require a dependency on itself to extract data (e.g., stack trace) from errors.

nitrocode commented 9 months ago

@mitar what about just the errors package? How does it compare?

I'm hesitant to push this project to replace an archived dependency for one that's uncommonly used (judging by project stars)

mitar commented 9 months ago

@nitrocode I completely understand. But it is a bit of chicken & egg problem. :-)

I think the questions for you is if you need/want stack traces or not. If you do, then this package provides almost the same API as the standard errors package, but with stack traces (see here for details). Also using this package and in the future (hopefully once stdlib gets stack traces) moving to errors should also be easy as my package provides compatible API. Of course, if you find additional helper functions it provides as well, for common patterns, useful, then you can use them as well.