shellfu/notes/TODO.md

TODO

global/misc

• persistence -- autocreate TMP, store things there

• flow.sh -- implement phase / outcome mechanism. Support for automatic mktemp/pushd/cp/popd/rmrf wrappng (make friends with collect_artifact*)

• fix up shellfu --list-*, current implementation is scratching right ear with left hand

• support conflict checking in shellfu. i.e. for TI and the likes

• doc - finish ffdoc, add first line to function lists

• trap EXIT to cleanup

• make better use of bash features and wipe out unnecessary grep/sed/perls

• separate core libs and extras

• maybe separate shellfu from core libs

test

• write some tests!

pretty.sh

• add -name arg to debug, e.g. for pipe/cmd/file and use it in pretty

• set fixed list of valid "leaks" to pretty

pretty*.sh

• implement options (like ps -o, et al.)

sw.sh

• support Beaker tasks in any_install

setup.sh

• make your own dog foo or use other than GNU make

testing.sh

• think: laziness, i.e. we only run actual test because it's only way how to obtain result. but could we have a way to preemptively "insert" the result based on cheap/fast/soft/safe check done e.g. by Harness? would that help make the whole damn thing less complex? (than w/ pre-selection?)

• outside test: setup, setupt, teardownt, teardown: fail=give up all hope.

  inside test: always teardownt, except if bailout before setupt was done (e.g. based on bugstate or feature check)

• phase outcome: fail, bailout (reason: waive, impossible, tool fail?), pass (1 per test phase?)

• collect_artifact -t -- make a timestamp-rooted copy of artifact tree or a particular artifact (with some implicit meta data)

• bugstate, bugstate_* -- ini-configurable bailout mechanism for bug-related contingency. use offline (iniread?) cache, provided by upper harness for, say, rhel7. (use expectedness?) e.g.

  bailout_if bugstate_open rhbz12345
  

  use a darn-simple buglist format (one that can work across many bugzillas el/fc/github/deb/whatever)

  make separate (ee*) independent tool to answer this query

• expected fail: s it possible/wise to support safely? Does it make sense in our architecture?

  consider jmarko's eval case with es=1 being expected.

  If expfail, make it uncommon as possible, e.g. 42 or 007.