Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core: expose LighthouseRunWarnings on audit context #5684

Merged
merged 1 commit into from
Jul 18, 2018

Conversation

brendankenny
Copy link
Member

@brendankenny brendankenny commented Jul 18, 2018

I was thinking about #5666 this morning and realized we shouldn't be altering artifacts in audits. Instead, this exposes a way to push top-level warnings from audits via the auditContext, similar to how gatherers can do so from the passContext.

happy to bikeshed on anything

Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this works for me :)

I'm not really sure I care about the distinction though. Is there a user-facing downside of mutating the artifact?

similar to how gatherers can do so from the passContext.

AFAICT, the gatherers are directly pushing onto the same array that gets exposed as an artifact, so it already seemed pretty much the same to me.

@brendankenny
Copy link
Member Author

Is there a user-facing downside of mutating the artifact?

In -A mode we still pass the artifacts back out, so you'd get the artifacts with an additional warning from what you passed in. In the CLI we don't save the artifacts if it's just -A mode, but if used as a node module, repeated processing would add more and more extension bootup time warnings to the run warnings. It is admittedly a minor problem :)

Mostly it's the conceptual cleanliness, which is why I mentioned being open to bikeshedding on the approach.

AFAICT, the gatherers are directly pushing onto the same array that gets exposed as an artifact, so it already seemed pretty much the same to me.

Right, and here it parallels that with audits pushing onto the warnings array that gets exposed on the LHR (which also includes the warnings copied from the artifact). Keeps artifact generation solely in gatherRunner and gatherers, but yes, in the end result functionally equivalent.

@brendankenny
Copy link
Member Author

In the CLI

actually, maybe it's observable in the CLI if run with -GA and then again with -A you'd get two copies of the warning in the resulting report, one saved from the original -A and one added by the second -A (you'd just max out at two warnings as the artifacts wouldn't be re-saved from the second run)

@patrickhulce
Copy link
Collaborator

Ah gotcha -A + node module, yeah makes sense! In CLI -GA, we should be saving the artifacts before audit mode so the saved artifacts should never have results of auditing, right?

if (settings.gatherMode) {
const path = Runner._getArtifactsPath(settings);
await assetSaver.saveArtifacts(artifacts, path);
}

either way, this seems good 👍

@brendankenny
Copy link
Member Author

In CLI -GA, we should be saving the artifacts before audit mode

oh riiiight, yeah, good call

@brendankenny brendankenny merged commit 8cee113 into master Jul 18, 2018
@brendankenny brendankenny deleted the auditwarnings branch July 18, 2018 22:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants