Pull request not created when using wlc
#12400
Comments
It seems that `wlc commit` followed by `wlc push` doesn't always create a PR (WeblateOrg/weblate#12400). This is the cause of the Weblate repository sometimes being locked without ever getting unlocked: unlocking happens on the PR-close workflow, but the PR never gets created. In fact, since we also run a `wlc reset` to avoid future merge conflicts, the `wlc reset` destroys all pending translator changes, which has happened to some contributors and now their work is gone. Add some sleeps to get a (presumably) async commit process to finish, and do an additional check for the `push` flag to reduce chances of data loss.
It seems that `wlc commit` followed by `wlc push` doesn't always create a PR (WeblateOrg/weblate#12400). This is the cause of the Weblate repository sometimes being locked without ever getting unlocked: unlocking happens on the PR-close workflow, but the PR never gets created. In fact, since we also run a `wlc reset` to avoid future merge conflicts, the `wlc reset` destroys all pending translator changes, which has happened to some contributors and now their work is gone. Add some sleeps to get a (presumably) async commit process to finish, and do an additional check for the `push` flag to reduce chances of data loss. **How to test** This is hard to test in isolation. We'll just have to monitor the GitHub Workflow runs over the next couple of days.
|
Do you have a log for the failed run? There might be something useful in Moreover, you might want to use squashing at Weblate side to avoid reset completely (but that might need other workflow adjustments). |
|
"push on commit" is not turned on, because sometimes Weblate will commit of its own accord (and hence push), and I only want the PR created at defined times of the day. Is the handling of
I did not run it with
Even if Weblate squashed on its end, it's unlikely it would come up with the exact same commit as GitHub would produce (same author, same commit message, etc). Yes we could regular-merge the pre-squashed commit, but it would need special scripting to handle Weblate PRs differently from other PRs (which are always squashed), and in any case we might need to do some final tweaks to Weblate PRs because we might need to adjust translations that have broken source code in them. So there is really no way of avoiding the
That's an idea! I suppose you're right that it shouldn't matter from the Weblate PoV. But I wonder if we'd run into an ordering problem there: the So we'd need the following steps in this order:
I'm not sure I can confidently script those events in GitHub. |
|
If you use rebase in git, it will look at the content of the commit and will discards commits with the same content. So it doesn't really matter how the commit messages or authors look like. Reset after merging the pull request is safe, even if there would be a merge conflict, it would be then reset to match upstream. |
Yes, but would the order not go like this:
? If so, we'd have an email every day warning us about a non-problem, hiding the cases when there's an actual problem. |
I know. That check will fail if we happened to mutate the PR while merging, which can happen because the translations contain source code which might contain problems that need to be fixed. It's a best-effort check that can fail, which is why I don't want to rely on it. |
|
Can you please tell me whether the handling of Thanks! |
|
One more question. If I do the following: I see the pull request being created. Is it expected that I still see |
We used to use `wlc repo` to try and see if Weblate flushed its changes to a PR. Weblate always shows `needs_push: True`, even if it *did* create a PR, so that is not a reliable check. Instead, we use the GitHub CLI to check for a PR with the title that Weblate always creates. We already check for the absence of such a PR at the start of the script, so if a PR exists at the end of it, it must be because Weblate created it, and we can safely reset. Context: WeblateOrg/weblate#12400
We used to use `wlc repo` to try and see if Weblate flushed its changes to a PR. Weblate always shows `needs_push: True`, even if it *did* create a PR, so that is not a reliable check. Instead, we use the GitHub CLI to check for a PR with the title that Weblate always creates. We already check for the absence of such a PR at the start of the script, so if a PR exists at the end of it, it must be because Weblate created it, and we can safely reset. Context: WeblateOrg/weblate#12400
|
Right now I'm not sure about |
|
Got you, thanks. I've changed to using the GitHub API to see if a PR was created. I also noticed that there can be quite a delay between an upstream repository change and Weblate pulling the changes. We had an interval of ~45 minutes the other day. Of course, a translator had translated in the interval between us merging the PR and unlocking Weblate, and Weblate actually performing the pull, so we had another merge conflict. Do you have statistics on typical values for the notification-pull delays? |
Describe the issue
In order to prevent merge conflicts, we use automation workflows that use
wlcto get Weblate to create PRs. Our workflow looks like this:wlc repoto check if there are changes, stop if there aren't anywlc lockall componentswlc pullwlc commitwlc pushwlc resetto force the repository back to a clean state, because the PR will be squash-merged and otherwise we would get merge conflicts on the next pullWhen the PR is merged, a workflow runs automatically in the
on_closeevent:wlc unlockall components againWe notice that occasionally, even though the repository shows
needs_commit: True, after running:No PR is created after all. Since no PR is created, our unlock workflow has no chance to run and the Weblate translations remain locked forever.
In the most recent case it was even worse: no PR was created, and as I mentioned
wlc resetwas run so all new translations were lost 😞 I figured this was safe because after runningcommitandpush, all changes would end up in the PR, but it turns out that sometimes no PR is created at all.A timestamp when this happened is 2024-09-01 06:15:32 UTC, on the Hedy project: changes were pending, but running commit and push didn't create a PR.
This is not consistent behavior. If I'd have to guess, I would say it happens in ~10% of cases... but with changes every day it happens often enough that it's quite disruptive for us.
What is the reason this happens? How can we write a script using
wlcthat will reliably create a PR if there are changes to commit?I already tried
Steps to reproduce the behavior
Write a script using WLC that looks like this:
Make changes to a Weblate translation, and run the script above.
In about ~10% of cases, no PR is created.
Expected behavior
I would expect a PR to be created in every case.
Screenshots
No response
Exception traceback
No response
How do you run Weblate?
weblate.org service
Weblate versions
No response
Weblate deploy checks
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: