Change Details

See PHI351. An install has 256+ character unit test names. I think this essentially always a problem before the data hits Phabricator (i.e., these names aren't useful to humans, either) but this is probably a case where we should give installs enough rope to shoot themselves in the foot. See also T11402, which discusses the total size of the test table. I expect that extracting these strings to a dimension table likely makes sense, with some absurd soft limit (like 1MB) to forestall disaster when an install uploads a unit test with a 750MB name and every interface becomes mysteriously slow. General questions about "which specific tests are failing" which storage changes should support: - T9365 is probably related but needs triage. - Same with T12029. - This gets a mention in PHI383. - T9951 wants this storage to have a basket of random properties. Maybe? This tends to make archival/storage more difficult but doesn't seem unreasonable. - T10123 is probably some aggregation of other stuff here. - See also T11763. T10635 is perhaps adjacent although I'm not sure what the current state of it is. Harbormaster build logs are mostly okay up to the storage part and then garbage from there forward. In particular: - (T5822) They should support archiving and GC. - (T9124) They should be accessible via the API -- but note issues with T5955 for logs with ANSI character codes. - (T9516, T8656, PHI382, T10179) The UI is generally clumsy and managing large logs is a headache. - (T6139) Build logs should support summarization. - (T11810) Live log output. - (T10868) Line-anchors. From PHI383: > What unit tests have recently failed? ... On which buildables? > What build plans have failed recently? ... On which buildables? > What build steps have failed recently? ... On which buildables? > What builds are running right now against buildables of this type? You can get //some// of this in the UI but it's very scattered. These are all largely reasonable questions to ask. Harbormaster doesn't do a good job of showing an overall "state of the world in builds" status dashboard or giving you the components to build one today. > What builds are running right now? What builds are running of a given plan? These can be answered at `/harbormaster/build/` but it (or some other interface) could be better at answering questions instead of just presenting information. > [ Which Drydock resources have had unit test, plan and step failures recently? ] > What builds are running within a given [Drydock] resource pool? > What builds has this drydock resource/resource pool had run on it? What build plans? What tests have failed on it? These are likely reasonable but the path is currently a little muddier since Harbormaster/Drydock have little explicit bridging today. See PHI405. This task discusses some reasonable improvements to the Harbormaster/Differential integration.

See PHI351. An install has 256+ character unit test names. I think this essentially always a problem before the data hits Phabricator (i.e., these names aren't useful to humans, either) but this is probably a case where we should give installs enough rope to shoot themselves in the foot. See also T11402, which discusses the total size of the test table. I expect that extracting these strings to a dimension table likely makes sense, with some absurd soft limit (like 1MB) to forestall disaster when an install uploads a unit test with a 750MB name and every interface becomes mysteriously slow. General questions about "which specific tests are failing" which storage changes should support: - T9365 is probably related but needs triage. - Same with T12029. - This gets a mention in PHI383. - T9951 wants this storage to have a basket of random properties. Maybe? This tends to make archival/storage more difficult but doesn't seem unreasonable. - T10123 is probably some aggregation of other stuff here. - See also T11763. T10635 is perhaps adjacent although I'm not sure what the current state of it is. Harbormaster build logs are mostly okay up to the storage part and then garbage from there forward. In particular: - (T5822) They should support archiving and GC. - (T9124) They should be accessible via the API -- but note issues with T5955 for logs with ANSI character codes. - (T9516, T8656, PHI382, T10179) The UI is generally clumsy and managing large logs is a headache. - (T6139) Build logs should support summarization. - (T11810) Live log output. - (T10868) Line-anchors. From PHI383: > What unit tests have recently failed? ... On which buildables? > What build plans have failed recently? ... On which buildables? > What build steps have failed recently? ... On which buildables? > What builds are running right now against buildables of this type? You can get //some// of this in the UI but it's very scattered. These are all largely reasonable questions to ask. Harbormaster doesn't do a good job of showing an overall "state of the world in builds" status dashboard or giving you the components to build one today. > What builds are running right now? What builds are running of a given plan? These can be answered at `/harbormaster/build/` but it (or some other interface) could be better at answering questions instead of just presenting information. > [ Which Drydock resources have had unit test, plan and step failures recently? ] > What builds are running within a given [Drydock] resource pool? > What builds has this drydock resource/resource pool had run on it? What build plans? What tests have failed on it? These are likely reasonable but the path is currently a little muddier since Harbormaster/Drydock have little explicit bridging today. See PHI405. This task discusses some reasonable improvements to the Harbormaster/Differential integration. See PHI446. This task discusses providing ways to access older builds and build logs instead of vanishing them from the UI completely.

See PHI351. An install has 256+ character unit test names. I think this essentially always a problem before the data hits Phabricator (i.e., these names aren't useful to humans, either) but this is probably a case where we should give installs enough rope to shoot themselves in the foot. See also T11402, which discusses the total size of the test table. I expect that extracting these strings to a dimension table likely makes sense, with some absurd soft limit (like 1MB) to forestall disaster when an install uploads a unit test with a 750MB name and every interface becomes mysteriously slow. General questions about "which specific tests are failing" which storage changes should support: - T9365 is probably related but needs triage. - Same with T12029. - This gets a mention in PHI383. - T9951 wants this storage to have a basket of random properties. Maybe? This tends to make archival/storage more difficult but doesn't seem unreasonable. - T10123 is probably some aggregation of other stuff here. - See also T11763. T10635 is perhaps adjacent although I'm not sure what the current state of it is. Harbormaster build logs are mostly okay up to the storage part and then garbage from there forward. In particular: - (T5822) They should support archiving and GC. - (T9124) They should be accessible via the API -- but note issues with T5955 for logs with ANSI character codes. - (T9516, T8656, PHI382, T10179) The UI is generally clumsy and managing large logs is a headache. - (T6139) Build logs should support summarization. - (T11810) Live log output. - (T10868) Line-anchors. From PHI383: > What unit tests have recently failed? ... On which buildables? > What build plans have failed recently? ... On which buildables? > What build steps have failed recently? ... On which buildables? > What builds are running right now against buildables of this type? You can get //some// of this in the UI but it's very scattered. These are all largely reasonable questions to ask. Harbormaster doesn't do a good job of showing an overall "state of the world in builds" status dashboard or giving you the components to build one today. > What builds are running right now? What builds are running of a given plan? These can be answered at `/harbormaster/build/` but it (or some other interface) could be better at answering questions instead of just presenting information. > [ Which Drydock resources have had unit test, plan and step failures recently? ] > What builds are running within a given [Drydock] resource pool? > What builds has this drydock resource/resource pool had run on it? What build plans? What tests have failed on it? These are likely reasonable but the path is currently a little muddier since Harbormaster/Drydock have little explicit bridging today. See PHI405. This task discusses some reasonable improvements to the Harbormaster/Differential integration. See PHI446. This task discusses providing ways to access older builds and build logs instead of vanishing them from the UI completely.