Skip to content

Change buf beta registry label archive/unarchive to buf beta registry archive/unarchive#2980

Merged
bufdev merged 4 commits intodevfrom
BSR-3748-BSR-3749-changes-to-archive-unarchive
May 15, 2024
Merged

Change buf beta registry label archive/unarchive to buf beta registry archive/unarchive#2980
bufdev merged 4 commits intodevfrom
BSR-3748-BSR-3749-changes-to-archive-unarchive

Conversation

@doriable
Copy link
Copy Markdown
Member

This PR changes buf beta registry label archive/unarchive to
buf beta registry archive/unarchive, which is able to take a
workspace input and archive/unarchive all labels for modules
in the workspace.
This UX change is needed to support uses-cases such as
GitHub Actions.

Copy link
Copy Markdown
Contributor

@saquibmian saquibmian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My comments are mostly about the command's docs; otherwise looks good.

Comment thread CHANGELOG.md Outdated
Comment thread private/buf/cmd/buf/command/beta/registry/archive/archive.go
Comment thread private/buf/cmd/buf/command/beta/registry/unarchive/unarchive.go
@saquibmian
Copy link
Copy Markdown
Contributor

I wonder if we should consider target modules in the workspace as well. The Archive/Unarchive RPCs currently does not allow archiving/unarchiving labels that don't exist. Does that pose a problem where the user would like to archive a label that only exists for some modules in the workspace but not for others?

@doriable
Copy link
Copy Markdown
Member Author

Does that pose a problem where the user would like to archive a label that only exists for some modules in the workspace but not for others?

I tried to bring this up yesterday, but I think it got a little lost. Right now the behaviour would be that this would error, since it's a single RPC call (per registry, but everything should be from the same registry), and I think this is a pretty reasonable behaviour. We are disallowing this for v1 workspaces, and so users with v1 workspaces would still need to continue with the workflows they already have to manage each individual module. This will start coming up for v2 workspaces, but I am okay with launching with the behaviour of error-ing and then going from there. But open to other's thoughts on this.

@nicksnyder
Copy link
Copy Markdown
Member

I think matching the API behavior here is fine since the alternative is just to target the specific modules that have the label you want to archive.

@bufdev bufdev merged commit bcf427c into dev May 15, 2024
@bufdev bufdev deleted the BSR-3748-BSR-3749-changes-to-archive-unarchive branch May 15, 2024 20:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants