proposal: fix proxy cache auth for registries with URL path prefixes

[mco69]

Signed-off-by: Mathieu C. 210950950+mco69@users.noreply.github.com

[reasonerjt]

Thanks @mco69, but as we discussed offline, this approach is preferred:
goharbor/harbor#22891

Let's keep this open unless we agree #22891 doesn't solve your problem.

[mco69]

@reasonerjt IMHO this is a better solution.

1. this is a very simple change, definitively much simpler than injecting headers
2. another way to look at this, this is just a bug fix to properly support Artifactory repository path model (when not fronted by a reverse proxy)
3. since this is already partially working, I'm not sure what is the upside in not completing the work? It's not like prefix support can be removed completely since it's already working (outside of the authentication issue)

[wy65701436]

lgtm

[wy65701436]

cc @bupd

[bupd]

Looks like the implementation proposed in goharbor/harbor/pull/22989 was already merged back in April.

This is the second time I am seeing something similar happen. Could we add some process enforcement here to prevent proposals from being bypassed or rendered moot after implementation has already landed? It makes the proposal process feel somewhat disconnected from what's actually happening in the repository.

Process is only as strong as its enforcement. Otherwise it becomes guidance rather than governance.

Also, should fixes even require proposals, or are proposals only intended for new features and larger architectural changes?

cc. @OrlinVasilev / @Vad1mo

[chlins]

lgtm

[wy65701436]

Looks like the implementation proposed in goharbor/harbor/pull/22989 was already merged back in April.

This is the second time I am seeing something similar happen. Could we add some process enforcement here to prevent proposals from being bypassed or rendered moot after implementation has already landed? It makes the proposal process feel somewhat disconnected from what's actually happening in the repository.

Process is only as strong as its enforcement. Otherwise it becomes guidance rather than governance.

Also, should fixes even require proposals, or are proposals only intended for new features and larger architectural changes?

cc. @OrlinVasilev / @Vad1mo

Agreed @bupd , we should definitely follow the right process here.

Although the changes are relatively minor and the author already did a live demo in the community meeting, we asked for a written proposal to give everyone better context and keep our process aligned.

While the changes look good to me, I won't merge this without your review and approval. Please share your thoughts on the proposal. If there are any concerns, we can address them before the author submits any further MRs.

[bupd]

/lgtm