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
During/after execution, failed notebooks would also be stored in the cache, in a separate
folder, with a 'failure record' that's linked to the 'staged record' (not yet implemented). This will be deleted when the notebook is unstaged or execution re-run.
Then, given a staged PK/URI, you can work out the build status, based on whether a complimentary commit/failure record exists, and retrieve any requisite data/notebooks.
The text was updated successfully, but these errors were encountered:
For html plugins to parse the reports we will need to define a default report structure. In QuantEcon we have used json with the following structure but we may want to think a bit more deeply about what fields we wish to record etc.
`JupyterExecutorBasic` has been restructured to:
- handle more exception
- have a better separation between cache access and notebook execution (may be changed further at a later date)
- Capture notebook execution, exception tracebacks and store them on the staged record (see README). This moves towards addressing #14
- Report final summary of executed/excepted on CLI
Also added an 'auto-generate' function for creating the CLI example section of the README
See: https://python.quantecon.org/status.html
This can be achieved by:
with commit records containing data like
execution_time
(as implemented in Allow the executor to save data to the commit record. #13)folder, with a 'failure record' that's linked to the 'staged record' (not yet implemented). This will be deleted when the notebook is unstaged or execution re-run.
The text was updated successfully, but these errors were encountered: