search

elcodi / github-webhook

Github Webhook to split main repo
1 stars 0 forks source link

Workers blocking stack #2

Open mmoreram opened 10 years ago

mmoreram commented 10 years ago

Block all github movements while split and tag workers are running.

We could work with a stack. Every time new commit or tag is added, both scripts should increment by one a simple stack. ASAP they finish, they should decrement this stack by one.

So, when new commits or tags, for example, are added, they should be refused as long as this stack is greater than 0 ( processes still running ).

With this feature, we could avoid the scenario of adding new commits while tag propagation is running.

mmoreram commented 10 years ago

ping @alch What do U think?

alch commented 10 years ago

It is already working this way :)

mmoreram commented 10 years ago

Ok, could you please point where is refusing new commits while workers are working?

alch commented 10 years ago

Sorry I got what you mean now. We already have a queue that work in the way you propose. However no blocking is enforced at github side: we have only one worker active, so there is no parallel execution. Events that insert in the github-split-queue will be served serially, since the subprocess in https://github.com/elcodi/github-webhook/blob/master/bin/worker.php#L35 is executed synchronically.

Ideally, we want the push event to pass the split process a commit, so that we would clone the repo and start the split & tag process from there. The worker should launch a single process that does the split & tag up to that commit.

Were you worried about some specific scenario about this? Since we do not do force pushes or move tags, even if we spawned several workers that could work concurrently, the worst that can happen is that a worker invoked from a previous push would find its pushes denied (being a no-ff push) when updating subpackages