Status: Closed (View Workflow)
- is blocked by
JENKINS-36170 API to determine if a step has logs or not
jamesdumay We get it from core, looking at the code it does File.length(), not sure how performant it is underneath. Keeping performance thing aside, that is even if for each step we give log file length size, it will only work for complete steps. for steps in progress or not yet run the log file length could be zero in that snapshot but later might or might not produce any log. so how do you intend to handle that case?
Right, if we don't know up front it has no log, I don't think we can do anything "nicely", and we just live with it.
There are common steps that don't have a log and we know that up front, and the change set for this addresses that, which is enough for me.
Code changed in jenkins
User: Thorsten Scherler
Jenkins 36171 Steps with no logs should not be expandable (#24)
- Debug logging of SSE events
- More on logging (client and server side)
- Better SSE connection disconnect cleanup
- Update to latest SSE gateway client api
- Use a relative path to logging.properties file
- Remove misleading seleium docs in readme (#11)
- [master] Fix last test by turning on cssPath again before finishing last test
- [master] try to fix freestyle error validation on server
- [master] comment the flaky test until I come up with something better. stop karaoke is covered in other tests as well
- [master] Add more comments to code
- [master] Change test to test positive. stop karaoke via keyUp is tested in noStage
JENKINS-36171implement test to see that steps that do not have logs neither are expandable
michaelneale yeah as @vivek stated we would need to actually fetch the log (at least the header) and see whether length is >0 and then could decide about the caret, however that is IMO way too much effort for the one/two steps that COULD provide a log but do not use that.
Can we make stats on those files cheap? Whats the penalty?