base-profiles: supports profiles with limited/no command usage

[jkellerer]

Implements #282

Waiting on #259 before completing it

Related updates in command completion will come separately

[codecov]

Codecov Report

Attention: Patch coverage is 56.21302% with 74 lines in your changes are missing coverage. Please review.

Project coverage is 69.71%. Comparing base (71ce2d0) to head (fd342c8).

Files	Patch %	Lines
commands.go	48.03%	58 Missing and 8 partials ⚠️
context.go	0.00%	8 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #290      +/-   ##
==========================================
- Coverage   69.88%   69.71%   -0.16%     
==========================================
  Files         118      119       +1     
  Lines       11891    12018     +127     
==========================================
+ Hits         8309     8378      +69     
- Misses       3193     3243      +50     
- Partials      389      397       +8     

Flag	Coverage Δ
unittests	69.71% <56.21%> (-0.16%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jkellerer]

@creativeprojects, the PR is updated to include command filter (& base-profile) support in runSchedule and I've extended it to allow running V2 schedules. It still misses more tests and a manual test.

Note: I've removed the comment that V2 configs will disallow inline schedules since I think this limitation isn't required. After all inline schedules are the only option to inherit configs and base-profiles make it possible to do so without side effects.

[creativeprojects]

Note: I've removed the comment that V2 configs will disallow inline schedules since I think this limitation isn't required. After all inline schedules are the only option to inherit configs and base-profiles make it possible to do so without side effects.

hmmm true; do we still need a separate schedule section after all? because we could allow the same schedule section to groups, as this was the missing piece basically.

[creativeprojects]

or maybe just moving all schedule-* options into a scheduling subsection, attached to a profile or a group. Maybe that would be nicer after all

[jkellerer]

Converting inline schedules to subsection would likely make it appear a bit nicer in yaml. For toml it may be less intuitive and we'd probably need to support both ways.

Well I think a separate schedule section does make sense as the runtime behaviour differs. Inline schedules all run individually, but the schedule section runs as a single item.

No sure if that can be fully implemented with groups in a way that is easier. It may work for groups if it uses multiple scheduling subsections, one for a possible command but is it easier? Would need to be checked separately with config examples (using toml also).

[jkellerer]

@creativeprojects , had just drafted how a unified Schedule instance could look like. For toml the differences are quite little. Think I changed my mind and like option 2 more as it fits more naturally in the current config file format. Nevertheless regardless of which may we may go, it shouldn't matter for this PR. In any case the code added here can be adjusted and reused. Let us continue discussion in #80.