3 ms·

You're making a... very tenuous argument, to say the least. For starters, your entire premise was "you don't have the run the build again". But now that I ask

You're making a... very tenuous argument, to say the least. For starters, your entire premise was "you don't have the run the build again". But now that I ask what you're going to do, you tell me you're... going to run the build again. So you've basically proven my point... you're going to waste that time sitting around anyway, and you'll need to reproduce it anyway, so just kick off an extra build or two in parallel if you need to correlate offsets. It's not like the 2nd one was going to be your last build anyway. Now re: diagnosing networks by looking at the byte offsets... so you correlate it (2 builds sufficed apparently?) and then... what exactly are you going to do now? This is GitHub Actions we're talking about, with dependencies downloaded from third-party servers. You're not managing either party's network or storage infrastructure to try to diagnose intermittent "network troubles". All you see is, for whatever reason, ubuntu/pypi/nuget/whatever isn't returning the full file. Maybe it fails in the same spot every time, maybe it doesn't. What exactly are you going to do differently based on what # byte it's failing to return? Either you can increase some timeout or switch to another server or whatever, or you can't. It's not like you're going to pull half the file and just use that. All the progress information does is satisfy idle curiosity and make you go "oh, that's funny...", and then you're left with the same options you had anyway. And honestly, how often does this even happen that you can't afford to tweak the build and increase the verbosity or whatever? These messages are just as useful as garbage >99.9% for the time, for the entire team... you really encounter these issues often enough (and find 2 builds sufficient for fixing them) to warrant that? To say I have a hard time swallowing this is quite the understatement.

saagarjha 6y ago
You still save a build, because (if needed) you can get results the next run rather than running two builds to figure out what went wrong. It’s not that I only have a chance to run two builds, but fewer builds saves time, especially in situations where running one takes a long time or things are falling over in such a way that it’s even hard to get a build scheduled. As for what I would do once I have that information…for GitHub Actions not much other than report it to someone who might actually have use for that information. But for internal CI it can be useful because it can tell you things like “oh the build always fails 30 minutes in, perhaps something is timing out” or “it always fails at 68%…hmm, I can download this file when not on the corporate network. Ah, the firewall doesn’t like that packet”. Again, I’m not saying I don’t agree with you that this is often not useful, but if you have a way to hide it away until it is necessary I would generally lean towards keeping it.

saagarjha 6y ago

You still save a build, because (if needed) you can get results the next run rather than running two builds to figure out what went wrong. It’s not that I only have a chance to run two builds, but fewer builds saves time, especially in situations where running one takes a long time or things are falling over in such a way that it’s even hard to get a build scheduled. As for what I would do once I have that information…for GitHub Actions not much other than report it to someone who might actually have use for that information. But for internal CI it can be useful because it can tell you things like “oh the build always fails 30 minutes in, perhaps something is timing out” or “it always fails at 68%…hmm, I can download this file when not on the corporate network. Ah, the firewall doesn’t like that packet”. Again, I’m not saying I don’t agree with you that this is often not useful, but if you have a way to hide it away until it is necessary I would generally lean towards keeping it.