add deployment visibility to konflux-info

[marcin-michal]

related to KONFLUX-8558, it is beneficial for the UI to be able to differentiate, if the current deployment is public or private

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: marcin-michal
Once this PR has been reviewed and has the lgtm label, please assign psturc for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi @marcin-michal. Thanks for your PR.

I'm waiting for a redhat-appstudio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[gbenhaim]

What is the reason th ui needs to know this detail?

[marcin-michal]

What is the reason th ui needs to know this detail?

On the namespace list page, there is a link to the internal documentation for instructions on how to create a new namespace. This should not be displayed on the public instances as it leads to possibly inaccessible places, as described in KONFLUX-8558

[gbenhaim]

@marcin-michal wouldn't be better to put the correct link to the documentation in the configmap?

[marcin-michal]

@gbenhaim yes, it probably would. One issue I'm not sure how to solve is that this particular page in the internal docs has no equivalent in the public docs, so it's not possible to just set the root docs URL here and specify the rest of the path for each button in the UI. Adding the URL to that specific page here (no URL set would mean not to display the button) also doesn't seem very elegant or scalable. What do you think?

[sahil143]

@gbenhaim For now we can proceed with just setting up the visibility in the config map, this is blocking a bug resolution. We can create a feature request to have docs direct links as part of config maps. Currently, there is only link (namespace documentation) in UI that's pointing to internal documentation.