support projects #428
support projects #428
Conversation
| @@ -66,6 +67,10 @@ async def add_secret(self, secret: Secret) -> None: | |||
| labels = {} | |||
| if secret.org_name: | |||
| labels[SECRET_API_ORG_LABEL] = secret.org_name | |||
| if secret.project_name == secret.owner: | |||
| labels[USER_LABEL] = secret.owner.replace("/", "--") | |||
There was a problem hiding this comment.
Unclear how we use this label later, maybe you could elaborate? (maybe, the plan was to utilize it in get_all_secrets instead of _get_owner_from_secret_name)
There was a problem hiding this comment.
why wasn't this comment addressed?
There was a problem hiding this comment.
sorry, didn't notice your comment. Yes, I think the plan was to utilize it in get_all_secrets first but then I decided to refuse from this approach. This should be removed, will do.
| Secret(key=key, value=value, owner=owner, org_name=org_name) | ||
| Secret( | ||
| key=key, | ||
| value=value, |
There was a problem hiding this comment.
minor: we probably could do value=value if with_values else "" end remove if-else
| if project_name: | ||
| label_selectors += [f"{PROJECT_LABEL}={project_name}"] |
There was a problem hiding this comment.
here we no longer respect USER_LABEL which we set for secrets belonging to projects named after owners.
we should have migrated to PROJECT_LABEL entirely as now these legacy and new labels cause confusion.
There was a problem hiding this comment.
I see, will remove project label selector and switch to filtering secrets in memory based on owner or project
closes #424