@melix my question is why we trigger this workflow like this? Why we don't trigger it when something is merged with master? We do the same in the metadata repository, here

I think it's done so that we only publish snapshots for successful pipeline. This would be to avoid that a snapshot from a broken master is published. But that's only a guess.

But we are performing checks before anything gets merged into master, right? So if we pass those checks, the master should be in the correct state? Or I am missing some edge case?

I don't think this was the case when this workflow was created.

Aha, okay. So should we keep this approach with workflows or we want to switch to the strategy we use in metadata repo? What do you think is the better solution in this case? I am fine with both

Both are probably ok, I have no preference either. Let's see if this one works.