TST: Update test to reflect new report generation behavior

[mgxd]

Closes #3209

The exit code for --reports-only should be an indicator of report generation status, not whether or not errors were present in the workflow (those should be reported separately, at the time they are encountered during processing).

[effigies]

I think we do still want to exit non-zero if there were errors detected. It's just that the error counting was removed from the report generation. I was about to work on this, but would you rather?

[codecov]

Codecov Report

Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (9568ccb) 72.03% compared to head (6fb9f17) 72.11%.
Report is 31 commits behind head on master.

Files	Patch %	Lines
fmriprep/cli/run.py	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3210      +/-   ##
==========================================
+ Coverage   72.03%   72.11%   +0.07%     
==========================================
  Files          55       55              
  Lines        4101     4145      +44     
==========================================
+ Hits         2954     2989      +35     
- Misses       1147     1156       +9     

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

[mgxd]

I'm going back and forth on this - now that we're examining it, it feels like there are separate cases.

1. During the regular workflow processing, absolutely, the return code should be nonzero as something went wrong, regardless of report generation result.

2. If running --reports-only, (1) had to have been run and the errors made apparent. So asking fmriprep to regenerate reports, which if it does, feels like it should return a "successful" code.

Perhaps we should expand the return code options and add a new one that specifies report generation was successful, but errors were present?

[effigies]

Ugh. I forgot that we split up the reports-only and the main implementation. Yes, if we're doing reports-only and it's not just a dry run with reports at the end, then sure, that can exit with 0 as long as the reports actually generate.

IMO the CI test is significantly less useful than it was when written, now that we duplicate report generation in two branches. We could just drop it or at least change it to grep for the error text in the HTML, rather than just checking the exit code.