gemmellr commented on PR #6036: URL: https://github.com/apache/activemq-artemis/pull/6036#issuecomment-3504940321
> > Removing this was also the reason why I removed the cleanup job - if we let github take care of all the cache, it wouldn't make sense to do the cleanup manually ... well, at least if we trust it. I'll take a closer look at what's being cached. > The cleanup is in there for a reason I assure you (I'm the one that put it there). Without it, it caches the build output, which is being installed as certain tests need it to be installed. Not having the cleanup can also and indeed has screwed us over in the past before it was done, more than a couple of build issues were masked due to it. Some then only getting hit at release time. I'd personally still want to use the cache action instead of the setup-java based stuff regardless. > > The maven download logging being there is actually desired > > I'm just beginning to play with this. I would ask - what's the minimum amount of logging that's desired? 100k lines in the log, mostly due to downloading, isn't great ... Actually it doesn't even load in the browser for me. I think removing the progress is a great way to keep the log smaller, while keeping the essential info. The next step, I'm thinking, is to suppress "[INFO] Downloading from ..." while keeping "[INFO] Downloaded from ..." > You'll only get extensive download logs if you have no cache. The main repo CI always has a cache. Forks will have one so long as its not your first activity in a week....or you do something like removing the existing caching stuff and thus forcing it to start afresh hehe. Easy enough to download the logs and inspect (though theyve opened in the browser for me, even in the past when we drove the significant test output to the console) Its also desirable to see the 'Downloading from' logs as well as the 'Downloaded from' ones in either case. I have on multiple occasions found repository config issues specifically due to those logs. In a separate case a ~terabyte of BW may or may not have been wasted over time due to all of the downloads logs being disabled hehe. > > various modules will run tests that cannot run at the same time, so that seems unlikely to be too reliable. > > Got there! ... > > > -T1C > > I ran nproc to check how many cores there are available, and the answer is 4. So theoretically this should help. But. I tried this with builds as well and it doesn't look like it's making a world of difference, plus ... it's the tests that take longer like you said. Yep its 4, has been for the last few years: https://docs.github.com/en/actions/reference/runners/github-hosted-runners -T1C does make a noticable difference with up to around 8 threads, but its not particularly useful if you arent actually waiting on it, which we arent really here. The tradeoff is also exceptionally ugly output (without going to things like mvnd), especially on failure (when we most need it), which for this job isnt a tradeoff I think is worthwhile. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
