Closed garvinhicking closed 1 month ago
I was testing this out both with
docker run --rm -v ${PWD}:/project -it typo3-docs:local --progress --config=Documentation --minimal-test
and ddev
ddev exec vendor/bin/guides Documentation --config=Documentation --minimal-test
In both cases all 3 versions got rendered:
docker run --rm -v ${PWD}:/project -it typo3-docs:local --progress --config=Documentation --minimal-test
Parsing: 13/13 [============================] 100% Parsed 13 files in 0.67 seconds
Rendering: 13/13 [============================] 100% Output format html: Rendered 13 documents in 2.99 seconds
Rendering: 13/13 [============================] 100% Output format singlepage: Rendered 13 documents in 0.03 seconds
Rendering: 13/13 [============================] 100% Output format interlink: Rendered 13 documents in 0.00 seconds
Successfully placed 13 rendered HTML, SINGLEPAGE, and INTERLINK files into /project/Documentation-GENERATED-temp
This might be due to the fact, that the main guides.xml also defines the output formats and these probably overrule the command? Not sure
You are probably right. I tested it without the 'config' directive. Need to inspect.
OK, this is too complex, I sadly have to give up. The guides.xml is loaded by guides after our decorator, there are dozens of config loaders and processors involved and I could not find a possibility to hook into it with for example an event listener, where I also would be able to get the original CLI input arguments.
We might need to first add this to guides
to be able to override guides.xml options. I've asked Jaap and begged for help :D
@linawolf Jaap hinted me at the PostProjectNodeCreated event in which I can hook into. It's not very beautiful code because I natively parse argv here, because the event doesn't seem to offer access to the original InputInterface from Symfony nor the InputDefinition.
Since we only access that single "--minimal-test" option I don't feel too bad about it.
However, I'm unsure what the 'fail-on-log' config option would do. I only can access 'setFailOnError()' on the projects settings, to 'Fail-on-log' seems to be something else. Do we need it? If so, we would probably need to set that one in the RunDecorator, but if that option is then part of a 'guides.xml' we cannot override it.
I am not really sure what fail on log did
Then I would suggest to continue ignoring it for the time being. The important flags (fail on error, singlepage output format) should work with the updated patch.
Did you test if we also fail on warning?
I only tested if the option was set and implied it should work. Needs testing/verification, you are right.
I just tested this and adjusted the make files to use the flag. How ever, once I use --minimal-test
no matter if I additionally --fail-on-log or not the runs are not returning a non-null status
I build one warning into the docs so we can test this
@linawolf Hm, the return status should be unaffected by this?! And "fail-on-log" is also unaffected. The only thing the patch at this point should do is adjust the output format, and enforce "fail-on-error" (NOT on warning).
I think warnings already have a success return code. Only errors would have another return code. Is the thing you added an error or a warning?
The thing I added is a warning. you can try this out by calling "make test-docs" locally. If you you remove "--minimal-test" from the command in the makefile the command fails due to the warning an the "fail on log". If you add "--minimal-test" it does not fail.
Alright, found it, I think.
'--fail-on-error' sets 'failOnError=error' '--fail-on-log' sets 'failOnError=warning'
Thus I changed the logic for the 'minimal-test' case to set failonError('warning').
This allows us to control specific settings needed for mininmal tests (like setting only a single output format) or more for the future.
Closes #764