Skip to content

feat: add checking in remote repo if manifest is a chart #3811

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

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

a1994sc
Copy link
Contributor

@a1994sc a1994sc commented May 15, 2025

Description

Makes call to zarf registry when trying to mutate ocirepo resource, and checks if the manifest is a helm chart

Related Issue

Fixes #3435

Checklist before merging

Copy link

netlify bot commented May 15, 2025

Deploy Preview for zarf-docs ready!

Name Link
🔨 Latest commit 7321088
🔍 Latest deploy log https://app.netlify.com/projects/zarf-docs/deploys/687ac04e4a937f00086470de
😎 Deploy Preview https://deploy-preview-3811--zarf-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

@a1994sc a1994sc marked this pull request as ready for review May 19, 2025 18:55
@a1994sc a1994sc requested review from a team as code owners May 19, 2025 18:55
@a1994sc
Copy link
Contributor Author

a1994sc commented May 19, 2025

Hey team, I believe that this PR is in a better state to be reviewed. I have fixed the unit tests to maintained backwards-compatibility with the current logic, e.i. if A) it can not reach the zarf registry, or B) if the media type is not of type helm. I also included a new unit test for checking with an in-memory registry, shoot-out to @brandtkeller for the awesome help both here in the PR and in DM's .

Please let me know if there are any changes you would like to make

Edit:

I will be also updating the docs and what not, so well the code stuff is ready for review the UX/docs needs to be updated

@a1994sc a1994sc requested a review from brandtkeller May 22, 2025 20:33
Copy link
Contributor

@AustinAbro321 AustinAbro321 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an excellent start, thank you for doing research and driving this forward!

Copy link

codecov bot commented May 27, 2025

Codecov Report

Attention: Patch coverage is 79.03226% with 13 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
src/internal/agent/hooks/common.go 82.35% 4 Missing and 2 partials ⚠️
src/internal/agent/hooks/flux-ocirepo.go 87.50% 2 Missing and 1 partial ⚠️
src/internal/packager/images/pull.go 0.00% 2 Missing ⚠️
src/internal/packager/images/common.go 0.00% 1 Missing ⚠️
src/internal/packager/images/push.go 0.00% 1 Missing ⚠️
Files with missing lines Coverage Δ
src/internal/packager/images/common.go 31.57% <0.00%> (ø)
src/internal/packager/images/push.go 52.28% <0.00%> (ø)
src/internal/packager/images/pull.go 53.16% <0.00%> (ø)
src/internal/agent/hooks/flux-ocirepo.go 82.64% <87.50%> (+1.20%) ⬆️
src/internal/agent/hooks/common.go 85.00% <82.35%> (-15.00%) ⬇️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@a1994sc
Copy link
Contributor Author

a1994sc commented May 27, 2025

This is an excellent start, thank you for doing research and driving this forward!

No problem at all!

@a1994sc a1994sc requested a review from AustinAbro321 May 28, 2025 19:54
Copy link
Contributor

@AustinAbro321 AustinAbro321 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few nits, and some test cleanup to be done. Overall changes are looking good.

@a1994sc a1994sc requested a review from AustinAbro321 June 2, 2025 20:30
@a1994sc a1994sc force-pushed the feat/oci-repo branch 4 times, most recently from db059bf to 1a89c64 Compare June 6, 2025 20:27
Copy link
Contributor

@AustinAbro321 AustinAbro321 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few small tweaks, otherwise looks good

s = &state.State{RegistryInfo: types.RegistryInfo{
Address: fmt.Sprintf("%s:%d", tt.svc.Spec.ClusterIP, tt.svc.Spec.Ports[0].Port),
}}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have some mixed feelings on how I implemented this part, where I override the test endpoint of the zarf docker registry, the tests do now pass... but Please let me know if you want me to rework it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks github for not saying that this wasn't visible to anyone else...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A cleaner solution could be to move up setupRegistry above the table tests, then add a field registryAddress to admissionTest. Then we can avoid the if statement, and each entry could own it's address

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intend to dig into this more intentionally asap - I am curious if this pattern tests the logic accordingly or is working-around it - but I need to step through the code. Will report back.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Appreciate the patience. Core functionality looks great but I'd like to revisit this test so as to have the purpose of the svc object in the admissionTest appropriately testing our logic for internal service lookup.

Spent some time mapping these changes to the test on main and do believe this is working-around the issue and not testing service discovery logic.

Stepping through the test -> NewOCIRepositoryMutationHook -> mutateOCIRepo -> GetServiceInfoFromRegistryAddress -> serviceInfoFromNodePortURL -> content

The workaround currently pre-sets the state to the internal IP:port - which isn't a valid state. So it fails in the early detection stages.

I'd like to see registry still set as the nodeport url 127.0.0.1:31999 and then identifying the internal service:port as intended. The ReplacePatchOperation should then be expecting the original 127.0.0.1:31999.

All of that said - it probably puts you back in the original spot. I can help run through the debugging more but do believe some of the root of the issue is that localhost was used in some of the tests for not mutating andserviceInfoFromNodePortURL() cannot actually handle that as expected (maybe a bug - maybe expected - needs refinement).

Appreciate your bearing with us as we get better about responding to these PR's.

Copy link
Member

@brandtkeller brandtkeller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the direction - appreciate your patience. Planning to step through the testing shortly but wanted to pass on some thoughts.

s = &state.State{RegistryInfo: types.RegistryInfo{
Address: fmt.Sprintf("%s:%d", tt.svc.Spec.ClusterIP, tt.svc.Spec.Ports[0].Port),
}}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intend to dig into this more intentionally asap - I am curious if this pattern tests the logic accordingly or is working-around it - but I need to step through the code. Will report back.

@a1994sc a1994sc force-pushed the feat/oci-repo branch 2 times, most recently from 1cd6678 to 8a62fe8 Compare July 1, 2025 21:35
Copy link
Member

@brandtkeller brandtkeller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great intent - want to see the testing provenance align otherwise looks great. Tough edge to solve.

s = &state.State{RegistryInfo: types.RegistryInfo{
Address: fmt.Sprintf("%s:%d", tt.svc.Spec.ClusterIP, tt.svc.Spec.Ports[0].Port),
}}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Appreciate the patience. Core functionality looks great but I'd like to revisit this test so as to have the purpose of the svc object in the admissionTest appropriately testing our logic for internal service lookup.

Spent some time mapping these changes to the test on main and do believe this is working-around the issue and not testing service discovery logic.

Stepping through the test -> NewOCIRepositoryMutationHook -> mutateOCIRepo -> GetServiceInfoFromRegistryAddress -> serviceInfoFromNodePortURL -> content

The workaround currently pre-sets the state to the internal IP:port - which isn't a valid state. So it fails in the early detection stages.

I'd like to see registry still set as the nodeport url 127.0.0.1:31999 and then identifying the internal service:port as intended. The ReplacePatchOperation should then be expecting the original 127.0.0.1:31999.

All of that said - it probably puts you back in the original spot. I can help run through the debugging more but do believe some of the root of the issue is that localhost was used in some of the tests for not mutating andserviceInfoFromNodePortURL() cannot actually handle that as expected (maybe a bug - maybe expected - needs refinement).

Appreciate your bearing with us as we get better about responding to these PR's.

@AustinAbro321
Copy link
Contributor

AustinAbro321 commented Jul 7, 2025

I tried the example here, but it seems that it's not connecting to the registry. I'm not sure why. Were you able to get this to work? I added a log to make sure that state is being pulled correctly and it seems that it is
image

@a1994sc
Copy link
Contributor Author

a1994sc commented Jul 7, 2025

I am seeing that as well... I will debug it and push an update

Correction.... I'm seeing the following error:

image

AustinAbro321
AustinAbro321 previously approved these changes Jul 11, 2025
Copy link
Contributor

@AustinAbro321 AustinAbro321 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, only thing that's a bit awkward is that the example won't work if someone tries it on the latest release of Zarf. No changes requested, but I might wait until we're a bit closer to release (July 25th) to merge

@a1994sc
Copy link
Contributor Author

a1994sc commented Jul 11, 2025

Ok, that works from me, Thanks @AustinAbro321

brandtkeller
brandtkeller previously approved these changes Jul 18, 2025
Copy link
Member

@brandtkeller brandtkeller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm - we did just merge the migration of the agent orchestration from manifests to helm chart - so this will require a quick conflict resolve.

@a1994sc a1994sc dismissed stale reviews from brandtkeller and AustinAbro321 via 7321088 July 18, 2025 21:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

FluxCD helm release fails when using ocirepo resource as chart reference
3 participants