-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Fix issue with addon directory not being linted #5592
Conversation
return ember(['test']); | ||
}) | ||
.then(function(result) { | ||
expect(result.exitCode).to.not.eql(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we also check the results.output
to confirm that the right test failed? Something like (stolen from another test I recently added):
var output = result.output.join(EOL);
expect(output).to.match(/TemplateLint:/, 'ran template linter');
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to do this; results.output
was undefined, and results.outputStream
didn't have anything in it that could be used to verify which test exactly failed.
@alexlafroscia - Looks really good, thanks for tackling. I left two comments (one is a bug and the other is more of a nit-pick) to address, then we can land this... |
25cde2b
to
6f2a45d
Compare
Alright, so I pushed an update to the previous commit that updates the acceptance-style test to use One thing that I was unable to do was verify the output text the way you mentioned. Inside the |
Fix issue with addon directory not being linted
Thank you @alexlafroscia! |
@rwjblue thanks for your help and guidance on this! I'm excited to finally be contributing to the CLI itself 😄 |
[BUGFIX beta] Fix addon linting regression. This was originally fixed in #5592, but likely regressed during the "great core-object migration of 2016" (:smiling_imp:). #5498 contains a good description of why using `eachAddonInvoke` doesn't work and shows the reasoning behind `_eachProjectAddonInvoke`.
Closes #5498