Closed dtfranz closed 3 months ago
Name | Link |
---|---|
Latest commit | bf85b3cb14133bd22e5daf3d3f010971b1285842 |
Latest deploy log | https://app.netlify.com/sites/olmv1/deploys/66914a8cf0571100098ef5c7 |
Deploy Preview | https://deploy-preview-1032--olmv1.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
General comment: there are likely some things copied over that are unused. I'll go through and make sure that's all removed.
Attention: Patch coverage is 66.56347%
with 216 lines
in your changes missing coverage. Please review.
Project coverage is 73.46%. Comparing base (
64f99f2
) to head (bf85b3c
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
General comment: there are likely some things copied over that are unused. I'll go through and make sure that's all removed.
I've removed everything I could find that was unused; see comparison here to see what I left out.
WDYT about dumping everything in under internal/rukpak
for now so that it's more obvious in a first pass what came from rukpak and what changed in existing operator-controller code?
I'm very much in favor of moving our rukpak code directly into this repo, but I'm also feeling a little bit like we need to (in a future PR) step back and take stock of our suddenly sprawling codebase to see if there are obsolete abstractions (e.g. unpack + storage) and other ways to reduce our package count and tidy things up a bit.
WDYT about dumping everything in under
internal/rukpak
for now so that it's more obvious in a first pass what came from rukpak and what changed in existing operator-controller code?
I'm very much in agreement with this and your other thought as well. Since I filtered out a lot of the types there's not currently much reason for the abstract types like storage
to exist in the codebase.
For now at the very least I'll move everything into the rukpak
subdir inside internal
.
For now at the very least I'll move everything into the
rukpak
subdir insideinternal
.
This is what I originally did for the original integration (before we pulled everything back)
We might possibly want to remove rukpak references from .golangci.yaml
, but not critical now. With this it appears that there are no references to the external operator-framework/rukpak
repo any more.
Looks as though a lot of the original code was not pulled over (good), and necessary changes made to only support imagev1.
@dtfranz, you'll need to rebase due to go.mod changes....
/lgtm
Moves rukpak code imported by operator-controller into the
internal/
folder.Fixes #997