-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace dep with Go modules #1584
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1584 +/- ##
==========================================
- Coverage 76.11% 76.09% -0.03%
==========================================
Files 163 163
Lines 13607 13607
==========================================
- Hits 10357 10354 -3
- Misses 2723 2726 +3
Partials 527 527
Continue to review full report at Codecov.
|
Something fishy is going on 😕 |
@na-- These were produced by |
I'd be fine if it was just pulling more files, maybe because it wasn't pruning or tree-shaking as much as dep, but look at the diff... There are differences in old files, which suggests that different versions were pulled. I want to update our dependencies soon, but that should be in a separate PR - this one should just encapsulate the switch of dependency manager. Please investigate what's happening, something is fishy. |
From my memories of when I tried to this a year ago ... one of the reason for changing versions is that now |
So it's a combination of several things:
For example, I'm not sure why these were updated, but since we were using very old versions, and these are semi-stdlib packages, we should consider updating them anyway, though we could pin them for now and do that later. Let me know.
|
As I said, I'm fine with the READMEs and new files that were previously pruned. I'd strongly prefer if we can leave the changes to actual dependencies in a separate PR, even |
OK, I'll see if I can pin the As for
😞 |
5d371cc
to
336872d
Compare
@na-- I version pinned some of the dependencies and the diff is much cleaner now. All additions now are just extra unrelated files that |
BTW, should this be fixed? On this branch:
On
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Went through the files, the missing ones are because they are //build +ignore
which in most cases is because those are files to generate other files so ... yeah :D.
About the version thing .. this is because of https://golang.org/pkg/runtime/debug/#ReadBuildInfo
now returns something ... which is what we want, I think the slight difference is not a problem ;)
If this works in all cases, it would elegantly solve #1584 (comment) .
If this works in all cases, it would solve #1584 (comment) .
844578c
to
ec5f107
Compare
Unfortunately, this doesn't fix flaky tests. 😆
Ah, that makes sense, thanks. I just wish there could be a way of configuring Serious question: what do you think about ignoring some of these at least at the repo level? Something like |
This will break the |
I'm not sure it will break the check. Considering that you can't check the integrity of the vendor folder with So, @imiric, my vote is 👍 for ignoring Makefiles, READMEs, |
If this works in all cases, it would solve #1584 (comment) .
ec5f107
to
19d8a1f
Compare
golangci-lint seems to be failing more often that not these days 😞 I added some |
I am not really certain the *.md files are worth it .. but can we also drop |
Not sure, those could be functionally significant 😄 |
If this works in all cases, it would solve #1584 (comment) .
19d8a1f
to
79a1425
Compare
If this works in all cases, it would solve #1584 (comment) .
79a1425
to
b73a228
Compare
If this works in all cases, it would solve #1584 (comment) .
b73a228
to
1e23d03
Compare
The latest |
@imiric, going through all the files in just in case and I noticed there are some surprising differences with |
Ah, nevermind, I think I answered my own question 😅 They seem like the non-library parts, an app you can use to generate your cobra boilerplate and docs or something like that... |
Yeah, I think this is just better pruning by |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, there are only a few more things we might want to ignore, like the perl scripts in vendor/golang.org/x/sys/unix/
, but they're not a big deal...
Closes #1070
This was prioritized because
dep
has an issue importing https://github.com/semihalev/sdns, which we're evaluating for the DNS fixes.There are some minor differences between
go.mod
and the previousGopkg.lock
. The missing packages are indirect and seem fine, and the version differences shouldn't cause problems, but let me know if they should be explicitly overriden.go.mod
but not inGopkg.lock
: