Repository navigation
feat(cli): write a log in the project when a command has a problem - #9
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A command that has a problem inside a project now leaves its log in
.miniops/logs/miniops.log: what it logged and the full traceback of the error. Until now nothing kept a traceback: an error that miniOPs reports ended with a short message and the traceback was lost.cli/log.py(new):CommandLogis alogging.Handlerthat keeps what a command logs in memory, the last 1000 records. The first warning or error writes all of it to the file, with the traceback, and every later record goes there directly. What was logged before the problem is the context that a bare traceback lacks..miniops/logs/. The log exists to diagnose problems: lines for successful commands would bury the errors and push them out of the size limit sooner, a read-only command should not write to disk, and the history of what was done belongs to the metadata store.MiniopsError) still showsError: <message>. An unexpected error now shows two lines instead of a traceback,Error: miniOPs hit an unexpected error (<type>: <message>). This is a bug.andDetails: <path of the log>, but only when the log was really written. Otherwise the traceback is still shown, as it is outside a project.handleError, and text that cannot be encoded as UTF-8 is written with escapes.miniops initalready adds.miniops/to.gitignore. It is opened only for each write, so no handle is held while a command runs. A file over about 1 MB is set aside asminiops.log.1at the first problem of a command, and if Windows refuses the rename because another process has the file open, the command adds to the existing file.loggingmodule, under the loggerminiopswithlogging.getLogger(__name__)in modules, and the local store logs the backup made before a schema upgrade and the new schema version.miniops/__init__.pyadds aNullHandler, because without one Python prints logged errors to stderr itself and an error outside a project would show twice.find_rootinconfig/project.pyis now public: the log needs only the project directory and must not fail on a brokenminiops.toml.Checklist
feat(registry): ...)CHANGELOG.mdupdated under "Unreleased"