Current state of the world here is:

Add line numbers and links to the log page with proper copy/paste behavior.

Add line numbers and links to the log page ... This is actually legitimately hard without scanning the entire file. Maybe we can emit a map as part of finalization which shows which has line markers every megabyte or so.

Maybe summarization and highlighting aren't the same object?

Very rough version of the new log:

As a note, pv can rate limit a pipe and is generally very useful all around.

this is a very good task :)

i used gem install so that i could remain ignorant of those types of problems

haha

I suppose welding does normally take a long time.

it has an -s option

There is a program far superior to cat that already exists.

Testing any of this is also a pain right now, so before any of that happens I'm going to write bin/harbormaster build --log output.txt or bin/harbormaster write-a-log or something. This overlaps the actual API-writing request in T9124, but that has more complicated concerns (like UTF8 issues, writing to a closed log, etc).

maybe a "grep" would be nice

I'm planning to tackle the build log stuff first since it's the most clear-cut, all fairly close together, and also roughly the most dumb.

The company I work for doesn't use Phabricator anymore. If I recall correctly the issue happens when an error occurs when creating the working copy. So DryDock create a copy 'copy-123' for example and then if an error occur (during the creation of the working copy for example can't fetch the repository), the build is stopped and the folder 'copy-123' is not deleted. DryDock will retry after 15s and create another copy 'copy-124'. So you can end up with millions of folders after a couple of hours.

When a blueprint uses concurrency-limiting slot locks, it currently just returns a random lock if it can't find a slot it suspects is free. This makes "all slots look fill, waiting for something to free up" ambiguous with actual collisions. It would probably be better to distinguish between these cases and make it more clear which one we're in.

After the patches above, I can't reproduce any bad behavior for T11495 or T10559.

I'm unable to reproduce this by following the instructions provided, at least after changes in T13073. Here's what I did:

After changes T13073, I am no longer able to reproduce this. That task has made some improvements and may have fixed whatever happened here.

My HoaxBlueprint does not implement activateLease(). This causes leases to be broken and destroyed.

Slightly more broadly: if the lease starts actually activating, we can't be sure that we can undo its state in the general case so we need to throw it away. But this failure (where the resource it has acquired doesn't activate) carries no such risk, and we can safely just throw it back in the pool. I think the only state we need to wipe out its its slot locks, which are easy to clean up.

Note that there's another similar scenario:

I just removed the setActivateWhenAcquired(true) for now without changing behavior. Next issue:

Alright, next issue:

Leases and resources don't use standard header UI tags to indicate status:

When logs span multiple lines, they are rendered as unreadable garbage messes:

When blueprints claim to be able to allocate resources but fail during allocation, we currently destroy the lease. I think this is likely too severe: consider an EC2 blueprint where the allocation call fails for some temporary reason (EC2 just fails, or we hit the account limit for instances, or whatever else).

In trying to plot a course through this, I'd like to try to sequence this so that existing issues get fixed first, then breaking changes happen afterward (maybe in the next release). Some of these changes (particularly, the CustomField-to-EditField change) will be significantly disruptive to existing custom code. (That change is also pretty straightforward and new stuff depends on it, so I'd probably start there if there was no compatibility concern.)

This doesn't really describe anything actionable.

This is something we could reasonably build now, but I think we're unlikely to build it without a customer request and an actual use case. Closing until those materialize.

Almanac's is a bit tight too