Yea this looks way better :-) Are you sure these are the only places we need to call it?

I think all commands that read a buf.lock are covered. I updated the PR description to give the full list of commands where this warning can be displayed.

There's also buf alpha sync here. That one's a little tricky because we scan commits in the past and we don't want to show the warning for all of them. We probably want to warn based on some timestamp? If commit was created after Nov 1st? I don't know how @bufdev feels about that, though.

What if we use a global variable to keep track of whether this warning has been printed, so that we only print it once? (or sync.Once)

What if we use a global variable

Mutable global variables to signal state are banned

That one's a little tricky because we scan commits in the past and we don't want to show the warning for all of them. We probably want to warn based on some timestamp? If commit was created after Nov 1st?

Kind of inclined to say that if you're using buf sync, you shouldn't see warnings of this nature at all. And let's say we implement "after a certain date (e.g. Nov. 1)", that commit will still be in their history, so even if they fix the issue, if they ever resync to a different repo, for example, they'll see it. I might leave buf sync out of this one, tbh. But yeah, @bufdev, I'll let you make the final call on this ^^"

if you're using buf sync, you shouldn't see warnings of this nature at all

The point of this is to give people an indication that they should migrate off of b3 digests. How do you think we should do that for repositories using buf sync?

As an alternative to all of this, we could instead show the warning in the BSR UI? It would be visible only to org members/admins. They are more likely to see it anyway, as users aren't in the habit of seeing warnings in CI runs.

As an alternative to all of this, we could instead show the warning in the BSR UI? It would be visible only to org members/admins. They are more likely to see it anyway, as users aren't in the habit of seeing warnings in CI runs.

Yeah, I think I'm more in agreeance with that sort of approach, because yeah, exactly, dealing with warnings in a CI run that aren't outright failures are often not priorities. And also, it's something they would need to handle by checking updates into source anyway (same with any dependency upgrade).

We chatted about this, and decided that we're not going to warn from sync, largely because it's highly likely that no one sees those anyway. The high value places to warn are build and lint, which are done.

Separately, we will consider a warning in the BSR UI, visible to repository members.