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

Support whether tools break a build or just comment #3

Open
bradleyfalzon opened this Issue Oct 31, 2016 · 0 comments

Comments

Projects
None yet
1 participant
@bradleyfalzon
Owner

bradleyfalzon commented Oct 31, 2016

Some users may choose that a particular tool:

  • comments on the affected line
  • comments on the issue itself
  • breaks a build (sets the status to failed)
  • a combination of the above

These should be configurable per tool see #8, and should always have an external link available in the status API showing a summary of issues per PR see #28.

bradleyfalzon added a commit that referenced this issue Mar 22, 2017

Write analysis to the database
This provides the foundations for a web view (discussed in #28),
so users can view the issues without relying on inline or issue
comments.

This also provides a mechanism to time how long the analysis is
taking as well as a per tool timing metric. This allows us to better
understand how much time different repositories or installations spend
checking.

We record which tools were executed, even if no issues were detected
so the user knows which checks passed. This will cause the analysis_tool
table to become very large over time.

Relates to #3.

bradleyfalzon added a commit that referenced this issue Mar 22, 2017

Write analysis to the database
This provides the foundations for a web view (discussed in #28),
so users can view the issues without relying on inline or issue
comments.

This also provides a mechanism to time how long the analysis is
taking as well as a per tool timing metric. This allows us to better
understand how much time different repositories or installations spend
checking.

We record which tools were executed, even if no issues were detected
so the user knows which checks passed. This will cause the analysis_tool
table to become very large over time.

Relates to #3.

bradleyfalzon added a commit that referenced this issue Mar 22, 2017

Write analysis to the database
This provides the foundations for a web view (discussed in #28),
so users can view the issues without relying on inline or issue
comments.

This also provides a mechanism to time how long the analysis is
taking as well as a per tool timing metric. This allows us to better
understand how much time different repositories or installations spend
checking.

We record which tools were executed, even if no issues were detected
so the user knows which checks passed. This will cause the analysis_tool
table to become very large over time.

Relates to #3.

bradleyfalzon added a commit that referenced this issue Mar 22, 2017

Write analysis to the database
This provides the foundations for a web view (discussed in #28),
so users can view the issues without relying on inline or issue
comments.

This also provides a mechanism to time how long the analysis is
taking as well as a per tool timing metric. This allows us to better
understand how much time different repositories or installations spend
checking.

We record which tools were executed, even if no issues were detected
so the user knows which checks passed. This will cause the analysis_tool
table to become very large over time.

Relates to #3.

bradleyfalzon added a commit that referenced this issue Mar 31, 2017

Write analysis to the database
This provides the foundations for a web view (discussed in #28),
so users can view the issues without relying on inline or issue
comments.

This also provides a mechanism to time how long the analysis is
taking as well as a per tool timing metric. This allows us to better
understand how much time different repositories or installations spend
checking.

We record which tools were executed, even if no issues were detected
so the user knows which checks passed. This will cause the analysis_tool
table to become very large over time.

Relates to #3.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment