feat: add configmap with mobster task git revision #6961
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: jedinym The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Hi @jedinym. 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 Once the patch is verified, the new status will be reflected by the 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. |
|
/verify-owners |
1 similar comment
|
/verify-owners |
|
/ok-to-test |
components/mobster/role.yaml
Outdated
| labels: | ||
| rbac.authorization.k8s.io/aggregate-to-view: "true" |
There was a problem hiding this comment.
I'm not sure this is required. Do we have any specific need for it?
There was a problem hiding this comment.
I was following this: #1511
We also need to use this CM in the e2e tests.
Do you know of a better way of achieving that?
There was a problem hiding this comment.
AFAICT, KubeSaw was used to bind each user to the view ClusterRole in each namespace the user has access to. That's something not supported from the new backend. As I understand it, adding it to the view ClusterRole should have no effect nowadays. Sharing with the system:authenticated group should work instead.
However, this means that every user in Konflux will be able to read the ConfigMap. Is this what we want to achieve here? From the PR description it seems to me we want to enable the release-service operator only, right?
The release-service operator needs access to a configmap with the git revision of Mobster tasks to use, to process SBOMs.
In this case, I think we should restrict to the release-service operator's ServiceAccount.
There was a problem hiding this comment.
The ConfigMap does not contain any sensitive information, so I would be fine with having it exposed to all. Do you think it's a bad idea still?
There was a problem hiding this comment.
If there is no need from users to have visibility on it and no particular reason for choosing this approach, I find scoping to the interested ServiceAccount only a cleaner solution
components/mobster/role.yaml
Outdated
| resourceNames: | ||
| - mobster-defaults |
There was a problem hiding this comment.
If we're scoping this to a specific resource, why do we need a ClusterRole? I presume this configmap isn't going to exist in all namespaces, so a Role is probably better here.
|
@sadlerap I added the ApplicationSet. Could you please clarify what you mean by "register it with the development overlay"? |
You need to ensure the applicationset for this component shows up in the overlays for the clusters you want to deploy it on. For instance, the internal production clusters are largely deployed by rendering the kustomize template at |
you can take inspiration from #5163, #5203, and similar PRs. In your case, you also need to target the |
Co-authored-by: Francesco Ilario <[email protected]>
|
@jedinym: The following test failed, say
Full PR test history. Your PR dashboard. 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. I understand the commands that are listed here. |
The release-service operator needs access to a configmap with the git revision of Mobster tasks to use, to process SBOMs. This mimicks the process that is already used by conforma to inject the git revision into release pipelines.
https://issues.redhat.com/browse/ISV-5876
https://issues.redhat.com/browse/ISV-6051