You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our Gitlab CI pipelines (internal, can't provide much details), we are invoking stack many times simultaneusly (build with different params, stack path etc.). And we are using the built-in docker integration (all commands thus start stack --docker. (We also have two different images we use, also simultaneusly, but that probably isn't related. Haven't tested that much.)
In this scenario, some stack commands fail with
SQLite3 returned ErrorBusy while attempting to perform step
Without knowing much about stack internals I suspect $STACK_ROOT/.stack/docker.db that it is failing to interact with when run in parallel.
This is annoying because as it causes pipelines to fail randomly.
Yes this looks like it's more a limitation resulting from using sqlite for tracking docker container state (or whatever that is used for). But maybe there's a way around it?
Steps to reproduce
Invoke multiple stack --docker commands simultaneusly, some of them should fail.
Expected
I expected stack to work just fine with parallel execution even when using docker integration.
Actual
Some (usually, just one) stack commands fail immediately with
SQLite3 returned ErrorBusy while attempting to perform step.
That's good to hear. I could take a chance at implementing a fix, but I can only think of hackish ways around. Then again I'm not familiar with the code base so don't know what to expect. Any nice ideas?
@SimSaladin Hey, that'd be great! I believe the relevant code is in Stack.Docker.GlobalDB. I think it makes sense to have a dedicated lockfile for the sql database. For this, use System.FileLock. There are already some examples of its use in the codebase.
In our Gitlab CI pipelines (internal, can't provide much details), we are invoking stack many times simultaneusly (build with different params,
stack path
etc.). And we are using the built-in docker integration (all commands thus startstack --docker
. (We also have two different images we use, also simultaneusly, but that probably isn't related. Haven't tested that much.)In this scenario, some
stack
commands fail withWithout knowing much about stack internals I suspect
$STACK_ROOT/.stack/docker.db
that it is failing to interact with when run in parallel.This is annoying because as it causes pipelines to fail randomly.
Yes this looks like it's more a limitation resulting from using sqlite for tracking docker container state (or whatever that is used for). But maybe there's a way around it?
Steps to reproduce
Invoke multiple
stack --docker
commands simultaneusly, some of them should fail.Expected
I expected stack to work just fine with parallel execution even when using docker integration.
Actual
Some (usually, just one) stack commands fail immediately with
SQLite3 returned ErrorBusy while attempting to perform step.
Stack version
Method of installation
stack upgrade
The text was updated successfully, but these errors were encountered: