Upgrade CRI-O to 1.16.3#514
Conversation
krawthekrow
force-pushed
the
debug-memleak
branch
from
485c6de to
57ad3fb
Compare
| name = "com_github_containers_conmon", | ||
| commit = "1bddbf7051a973f4a4fecf06faa0c48e82f1e9e1", # 2.0.15 | ||
| importpath = "github.com/containers/conmon", | ||
| build_file_generation = "off", |
There was a problem hiding this comment.
If we're turning off build file generation, what's the point of having this be a go_repository rule instead of a git_repository rule?
There was a problem hiding this comment.
The git_repository rule seems to cause the patched-in symlink to no longer be a symlink for some reason, and I can't figure out why. In any case, I'll change the go_repository_alt back into a go_repository.
There was a problem hiding this comment.
Okay; we might want to do some digging on that at some point. If you don't want to do it now, can you file a low-priority issue?
krawthekrow
force-pushed
the
debug-memleak
branch
from
57ad3fb to
7337ddb
Compare
This involves: - Separating out the conmon build (following the upstream change) and giving it its own bazel build file patch. - Removing the conmon tests since they require additional build dependencies that we don't need. - Regenerating the CRI-O build file patch. - Updating the CRI-O upstream config file. - Updating deps.bzl.
krawthekrow
force-pushed
the
debug-memleak
branch
from
7337ddb to
cace7b1
Compare
celskeggs
left a comment
celskeggs
left a comment
There was a problem hiding this comment.
One nitpick and some issues to file for later. Very nice!
| + "src/*.c", | ||
| + "src/*.h", | ||
| + ]), | ||
| + # TODO: get these dynamically, not statically |
There was a problem hiding this comment.
I know these two TODOS were already here, but while we're looking at it, can we make sure we file issues to get back to them?
| + name = "conmon", | ||
| + srcs = glob([ | ||
| + "src/*.c", | ||
| + "src/*.h", |
There was a problem hiding this comment.
I think you're mixing tabs and spaces here.
2 participants
See commit message. Unfortunately this does not seem to fix the memory leak, and the number of exit files still grows apparently unboundedly.
See #490 .
Checklist: