Remove dockerfile from checker

[christoph-zededa]

No description provided.

[deitch]

Why are we moving this out of here and into lf-edge/eve?

[christoph-zededa]

Why are we moving this out of here and into lf-edge/eve?

Besides lf-edge/eve#4334 (comment) there are some more reasons:

• many tools are already in the eve repository
• eve-build-tools repository misses checks, for example checking for license headers
• the dependabot is not set up? (it immediately worked build(deps): bump github.com/docker/docker from 25.0.1+incompatible to 25.0.6+incompatible in /tools/dockerfile-from-checker eve#4343 )
• the eve-build-tools repository is kind of unknown

[deitch]

some more reasons

The eve-build-tools probably should be better known, agreed.

The argument you are making is basically for a monorepo with everything in it. We cannot afford that. Let's say that tomorrow there is a new version of the dockerfile frontend. Do you really need to go through all of the long slow eve CI, and tie up runners, just to update that tool? You might want to once you are sure the tool is ready, but not before that. That is what libraries are about: modularization.

EVE repo is way too big and heavy. We didn't like moving the api out to eve-api repo either, but it was critically necessary.

[christoph-zededa]

The argument you are making is basically for a monorepo with everything in it. We cannot afford that.

No everything. F.e. no gcc sources or kernel sources. Also we just added another 4k files for rust ...

Let's say that tomorrow there is a new version of the dockerfile frontend. Do you really need to go through all of the long slow eve CI, and tie up runners, just to update that tool? You might want to once you are sure the tool is ready, but not before that. That is what libraries are about: modularization.

No, that's why I am also working on lf-edge/eve#4202 (slowly working on it though)

Are there any other reasons why we cannot afford that?

---

Okay, so you are advertising to use a multi-repo strategy, but unfortunately we lack the infrastructure to do so:

• no sync of GH actions between the repositories
• no sync of Makefile targets between the repositories (f.e. yetus)
• manual work to bump up revisions (f.e. eve-api or eve-kernel)
• no organized way to update all repositories locally like f.e. https://gerrit.googlesource.com/git-repo

[deitch]

We already do use a multi-repo strategy, and a mono-repo, at the same time.

some of it always will be multi-repo: kernel, eve-api, libs. There are solid reasons for it.