feat(controller): allow GitHub App as authn method for image repos in ghcr

[Dhouib-Mohamed]

Fixes #2383
Accepting credentials.TypeImage in the getCredentials condition
Adding Necessary tests linked to TypeImage to validate te changes

[netlify]

✅ Deploy Preview for docs-kargo-akuity-io ready!

Name	Link
🔨 Latest commit	f2a947a
🔍 Latest deploy log	https://app.netlify.com/sites/docs-kargo-akuity-io/deploys/66b34325d1664f00084223a2
😎 Deploy Preview	https://deploy-preview-2391.kargo.akuity.io
📱 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.

[krancour]

@Dhouib-Mohamed there's still about 81 more changed lines in this PR than I was expecting...

[Dhouib-Mohamed]

I created the cache hit and the cache miss testes for both Git and Image because i maybe depends on the type of the credential since it is not just checking the inputs like secret and app id and it contains business logic
Should i createb one case only for git for those as well?

[krancour]

@Dhouib-Mohamed if you look at how the cache keys are constructed, the repo type has no bearing on it.

[krancour]

These two new cases are still not needed. I know this may seem counter-intuitive, but remember this is white-box testing...

The previous case (cred type not supported) tests for an early return if the cred type is not supported. Subsequent cases only require the cred type to be a supported one so that we avoid that early return and move on to testing other outcomes. Again, with white-box testing, we have the luxury of knowing the implementation and we know that once we're past that potential early return, the cred type has no further bearing on the results.

[krancour]

@Dhouib-Mohamed the changes look good. Thank you for your patience with the review process.

Did you happen to test this end-to-end? i.e. Take it for a test drive?

[Dhouib-Mohamed]

I tested a basic scenario (creating a credential from the ui) but i am not sure if i covered the necessary use cases
To be frank even now i am not sure about the usage of this function since this is my first interaction with this project
If possible can you give an example of a full use case to test?

[krancour]

@Dhouib-Mohamed this code doesn't really have anything to do with creating creds via the UI. This has to do with the back end retrieving temporary access tokens associated with a GitHub App.

If I were testing this, I would write a small, standalone program that instantiates this credential helper and I would pass it a Kubernetes Secret I created myself, programmatically so test whether it returns the temporary token. If it does, I would copy that and test your ability to use that token to log into the Docker CLI and pull a private image from ghcr.

[Dhouib-Mohamed]

Got it
Thanks for clearing that out for me
I will go ahead and test it and make any necessary changes

[Dhouib-Mohamed]

@krancour I have made the necessary tests and i have concluded that even with adding packages permissions to the Github app it still return a Not Authorized error when trying to interact with Github Packages ( images ).
This is a discussion found explaining the problem : https://github.com/orgs/community/discussions/34324

That's why i think that this PR should be closed for now.

[krancour]

@Dhouib-Mohamed that discussion indeed looks like it doesn't work in our favor here. I'm going to a test a little as well and report back.

One thing that I expect is a factor here -- and so I want to ask if you took it into account -- if the App has packages:read permission and is installed into a Git repo (and not installed org-wide) then the package (container image) in question must "belong" to that Git repo. (This really isn't the most intuitive thing, honestly. I believe that if this does work, this is probably where most people go wrong.)

So:

1. Did you install at the Git repo level? Or org level?
2. If at the Git repo level, are you certain the package belonged to that Git repo?

As I said, I will experiment as well, but it is quite possible that you are correct and this isn't doable at the moment.

[Dhouib-Mohamed]

@krancour So i tested on Git Repo level and on organization level and they both failed
On Git Repo lever i made sure that the package belong the repo ( linked to the repo ) and i tried to link the github app to all the repos or to a specefic repo and they both failed

Do you want me to share the code i created to test this out to simplify your testing?

[krancour]

@Dhouib-Mohamed I appreciate your thoroughness! I don't need the code... I think I can do that pretty quickly. It's the setup on the GitHub end of things that is the more time consuming part. 🤦‍♂️

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 47.61%. Comparing base (a01f049) to head (f2a947a).
Report is 11 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2391      +/-   ##
==========================================
- Coverage   47.63%   47.61%   -0.03%     
==========================================
  Files         244      244              
  Lines       17396    17394       -2     
==========================================
- Hits         8287     8282       -5     
- Misses       8698     8700       +2     
- Partials      411      412       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[krancour]

@Dhouib-Mohamed thank you so much for the non-trivial amount of effort you put into this. I can independently confirm your findings. Despite all appearances (a package permissions option when configuring a GitHub App), an App installation token simply cannot enable access to a private ghcr.io package repository. ☹️

I will close this PR for now, but it is my hope that someday this will work and this PR can be revived.