In &7650 (comment 1101343959) we discussed the need for developer documentation for the Harbor integration. Once done, this will allow the groupcontainer registry to maintain the code and remove all relevant feature flags.
Proposal
Once the developer documentation is complete, we will review it and ensure that the team feels comfortable supporting this new integration.
If you do not feel the purpose of this issue matches one of the types, you may apply the typeignore label to exclude it from type tracking metrics and future prompts.
@adie.po, from my understanding, we just need to do (1) and determine if there is any missing information we need before taking over the maintainership of this feature.
Have also been able to test it in staging and local environments
Authenticating as a harbor user works
Delete, push, pull works
Questions / Wonderings:
A. Test Settings feature
I shared an observation here and asked for clarification re: the Test Settings feature.
Also commented in the documentation to mention the Test Settings feature and its expected behavior (i.e. I always get a Connection Successful even if it's the wrong password or non-existent project name).
B. Inconsistent Validation error
This is minor and does not affect functionality.
When enabling the integration, Project name and Harbor username are both required but looks like they have different validation methods:
Harbor username is validated through an HTML required. It blocks the submission of the form when username is not present.
Project name is validated through rails form validations. The form continues to submit and hit the server even if the project name is empty. The error happens on the rails side.
Ideally, Project name should also have a HTML required validation so it does not need to make a call to the server as it is already required in the HTML. The same validation method also provides for a more uniform user experience.
A. Harbor Username with a HTML error
B. Project Name with a Rails form error
@trizzi@michelletorres From &7650, the feature is behind a feature flag with a percentage already released in production, The JiHu team is aiming to release it fully. For (B) above, is this something we want to raise and be fixed before the full release or are we OK to have this fixed later (after their release). cc: @rchanila@jdrpereira
We have done (1.) and (2.) so was wondering if we can consider this issue complete?
It was mentioned above about removing the feature flag for this but it is a part of their rollout issue when they fully release: #353595 (closed) so maybe it is outside the scope of this issue?
@adie.po - as you are confirming the code and docs are clear and there is nothing pending for us to support the integration, then this issue is ready to be closed.
@rchanila When you have all issues created, we should share the list in &7650. In the same comment and because those issues are no blockers, we should ping @orozot so they proceed with the rollout.
When you have all issues created, we should share the list in &7650. In the same comment and because those issues are no blockers, we should ping @orozot so they proceed with the rollout.
Will let them know they can proceed with feature flag rollout.