Skip to content

build: ensure only errors are displayed in issue via log file #5751

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

Draft
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

Planeshifter
Copy link
Member

Description

What is the purpose of this pull request?

This pull request:

  • adds support for an ESLINT_ERROR_LOG variable to store errors when running eslint-files make rule.

Using the JSON formatter as suggested in the issue and discussed doesn't help much since we process each file individually and would then still need to parse out the results for them. Instead, I ended up settling on re-running the ESLint command with --quiet to ensure only errors get reported and appending the results to a log file whenever linting of a file fails.

Related Issues

Does this pull request have any related issues?

This pull request:

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.

Checklist

Please ensure the following tasks are completed before submitting this pull request.


@stdlib-js/reviewers

---
type: pre_commit_static_analysis_report
description: Results of running static analysis checks when committing changes.
report:
  - task: lint_filenames
    status: passed
  - task: lint_editorconfig
    status: passed
  - task: lint_markdown
    status: na
  - task: lint_package_json
    status: na
  - task: lint_repl_help
    status: na
  - task: lint_javascript_src
    status: na
  - task: lint_javascript_cli
    status: na
  - task: lint_javascript_examples
    status: na
  - task: lint_javascript_tests
    status: na
  - task: lint_javascript_benchmarks
    status: na
  - task: lint_python
    status: na
  - task: lint_r
    status: na
  - task: lint_c_src
    status: na
  - task: lint_c_examples
    status: na
  - task: lint_c_benchmarks
    status: na
  - task: lint_c_tests_fixtures
    status: na
  - task: lint_shell
    status: na
  - task: lint_typescript_declarations
    status: na
  - task: lint_typescript_tests
    status: na
  - task: lint_license_headers
    status: passed
---

---
type: pre_push_report
description: Results of running various checks prior to pushing changes.
report:
  - task: run_javascript_examples
    status: na
  - task: run_c_examples
    status: na
  - task: run_cpp_examples
    status: na
  - task: run_javascript_readme_examples
    status: na
  - task: run_c_benchmarks
    status: na
  - task: run_cpp_benchmarks
    status: na
  - task: run_fortran_benchmarks
    status: na
  - task: run_javascript_benchmarks
    status: na
  - task: run_julia_benchmarks
    status: na
  - task: run_python_benchmarks
    status: na
  - task: run_r_benchmarks
    status: na
  - task: run_javascript_tests
    status: na
---
@kgryte
Copy link
Member

kgryte commented Mar 4, 2025

Using the JSON formatter as suggested in the issue and discussed doesn't help much since we process each file individually and would then still need to parse out the results for them

Why wasn't the Unix formatter suitable?

@Planeshifter
Copy link
Member Author

Planeshifter commented Mar 4, 2025

@kgryte

If we used the Unix formatter, we would get output like

/var/lib/jenkins/workspace/eslint Release/eslint/fullOfProblems.js:1:10: 'addOne' is defined but never used. [Error/no-unused-vars]

We could implement this and then use grep to filter lines containing [Error. However, I find this output less appealing than the default formatting. Second, we would need to maintain the previous tee approach in order to print to both stdout and a file then. Finally, we would need to either use a deprecated ESLint formatter (no longer available in v9) or add that external dependency. In comparison, I find the make rule variable for storing errors simple and clear.

@kgryte kgryte self-requested a review March 24, 2025 07:25
@@ -335,31 +335,31 @@ jobs:
done
Copy link
Member

Choose a reason for hiding this comment

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

I suggest moving this logic to a separate Bash script. This will make refactoring and linting easier.

@kgryte kgryte added Needs Review A pull request which needs code review. Tools Issue or pull request related to project tooling. CI Issue or pull request specific to continuous integration environments. Needs Changes Pull request which needs changes before being merged. and removed Needs Review A pull request which needs code review. labels Apr 16, 2025
---
type: pre_commit_static_analysis_report
description: Results of running static analysis checks when committing changes.
report:
  - task: lint_filenames
    status: passed
  - task: lint_editorconfig
    status: passed
  - task: lint_markdown
    status: na
  - task: lint_package_json
    status: na
  - task: lint_repl_help
    status: na
  - task: lint_javascript_src
    status: na
  - task: lint_javascript_cli
    status: na
  - task: lint_javascript_examples
    status: na
  - task: lint_javascript_tests
    status: na
  - task: lint_javascript_benchmarks
    status: na
  - task: lint_python
    status: na
  - task: lint_r
    status: na
  - task: lint_c_src
    status: na
  - task: lint_c_examples
    status: na
  - task: lint_c_benchmarks
    status: na
  - task: lint_c_tests_fixtures
    status: na
  - task: lint_shell
    status: na
  - task: lint_typescript_declarations
    status: na
  - task: lint_typescript_tests
    status: na
  - task: lint_license_headers
    status: passed
---
@Planeshifter Planeshifter marked this pull request as draft April 25, 2025 23:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI Issue or pull request specific to continuous integration environments. Needs Changes Pull request which needs changes before being merged. Tools Issue or pull request related to project tooling.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[RFC]: Improve JS lint issue content to include only failing cases
3 participants