Retrying failed builds is important, but difficult for new users
Summary
In theory, users should have fully reproducible builds, and it is not necessary to retry builds.
In practice there are numerous issues that lead to a need for retrying:
- Race conditions in the build.
- Limited memory.
- Limited disk space.
- etc.
Here are the difficulties with retrying as I see them, will create separate tickets depending on how this discussion goes:
- Retrying a build with 'r' does not try to rebuild, it uses the cached failed build. (It retries the 'build job' not the build).
- A subsequent 'bst build' fails immediately, perhaps it could offer 'retry' and 'logs' options as with first run.
- 'bst build' failure doesn't signpost commands that can help from there, e.g. 'artifact logs' and 'artifact delete'.
How to repro:
git clone https://gitlab.com/buildstream/buildstream.git
cd buildstream/doc/examples/running-commands
bst build hello.bst
# -- Should be ok up to here --
echo " - sleep 10" >> elements/hello.bst
echo " - 'false'" >> elements/hello.bst
bst build hello.bst
# .. wait 10 seconds for it to fail ..
# Choose:
# (r)etry - Retry this job
# .. instantly fail again, no 10 second wait ..
bst build hello.bst
# .. instantly fail again, with only the failed command mentioned, logs would be nice ..
bst artifact log hello.bst
# Ok, now I can see the log, but I didn't get a signpost from the 'bst build' instafail.
bst artifact delete hello.bst
bst build hello.bst
# Hurrah, I retried :)