jboss-set / bug-clerk Goto Github PK

It is difficult to maintain and makes works properly across tools (bz, jira) and version number (6.x, 7.x) and it has yet to report anything else but false+.

If using Bugclerk, 0.8.0 and 0.8.1, with the "add comment" feature (-c), BugCLerk will crash, due to the misplaced close() statement, disconfiguring Aphrodite before calling the addComment method. This will be fixe in 0.8.2.

If an issue is a payload tracker, such as BZ1386335, the check will verify that the version mentioned in the subject (EAP 6.4.13) matches the one set for the issue (6.4).

In https://bugzilla.redhat.com/show_bug.cgi?id=1174152#c1 the bot approved the BZ for 6.3.z CP, while the BZ was actually a feature request.

Maybe report the issue if the BZ meets one of the following criteria:

• More than 3 (or 5 ?) comments
• NEW for more than a month
• has PR !
• ...

Check if dependency of a resolved JBEAP issue is being associated to a Resolved issue with a Fix Version , a "component upgrade" issue should be attached to the JBEAP issue.

Anything can be put into a PR fields ! Better checks that

There is a file attached with a commit.
Not allowed to make PR in the repo.
Bug-Clerk detects it as an error.

Check https://bugzilla.redhat.com/show_bug.cgi?id=1167348

BugClerk says:

"[ReleaseVersionMismatch] Release in title does not match actual release (6.3.0]:(6.4.0) ...bz title"

But "target release" in that BZ is set to "EAP 6.4.0". Is that legit?

Provide white list for users that "CAN" alter fix version without being annoyed. This is kind of a feature to gently phase out folks from abuse of "Fix Version" field. Basically, if UID is not on the white list, bugclerk should add comment to issue and send warning to jboss-set ?

For instance, if there is no PR to be associated to a BZ, it would nice to be able to simply add a specific comment (ex: BugClerk#NoPR) to give a hint to BugClerk that it should not report the issue.

Guard against high priority issues stranded for too long without assignee: priority/severity - possibly we should get a initial warning on email or list and than guard against it being left rotting.

At first glance, I would propose that "too long" is over two weeks.

Will help move Violation to Aphrodite later on.

payload -> upgrade -> component fix

• relational constraint, if fix is in payload, upgrade must be there and be in payload. If upgrade is in payload, fix must be as well.

This will be implemented in two checks:

1. Any fixes belonging to a payload tracker will be analysed to check for a component upgrade in the depends list
2. Any Component Upgrades, belonging to Payload Tracker, will be analysed to check they are tied to a bug fix.

This happens when the PR is attached as a patch to the BZ because the SCM is the SVN (jboss-web project)

When a BZ has been acked positively by qa, pmd and dev, all its dependencies should also have such flags. This check aims at spotting such discrepencies.

When a BZ status is moved from ASSIGNED to POST or when it is getting a dev_ack+ flag, it must have a time estimate associated set.

Once issue is "resolved" no changes should be allowed, no PRs linked, no state change. Unless it happens, all sirens should flare up, example: https://issues.jboss.org/browse/JBEAP-5271 ( all view )
Jan Blizňák made changes - 11/Aug/16 7:55 AM

Like BZ1217239.

If a BZ is not linked to an upstream, JIRA issue, it should be justify by a comment featuring the sentence "no upstream required because..."

The body of the generated is garble and contains several times the same issue. This will be fixed in 0.8.3.

I would recommend bug-clerk to disable some rule checking for VERIFIED valid issue, or CLOSED invalid issue (such as duplicate or not a bug)
see https://bugzilla.redhat.com/show_bug.cgi?id=1172830#c10

When sprint is up for CP, no version changes should be allowed, unless RC or GSS perform them.
ie. if Sprint 7.0.6 ( payload freeze) is up, any change of fix version in range [7.0.6 CR1,...) can't be performed by any other party than RC or GSS(?) ? If it happens, alarm should sound.

For instance, attaching a 7.0.x issue to a component upgrade targeted against 7.z

check PR details (repository, branch, etc..) in help with stream service in Aphrodite.

There is comment from BugClerk on https://issues.jboss.org/browse/JBEAP-821, that says

"[BZDepsShouldAlsoHaveFlags] This issue is referenced by JBEAP-2770, which has all qa+,pm+ and dev flag+ - but not this issue."

Which is not true. For JBEAP-2770, the correct message should be :

"[BZDepsShouldAlsoHaveFlags] This issue is referenced by JBEAP-821, which has all qa+,pm+ and dev flag+ - but not this issue."

Indeed, JBEAP-2770 with insufficient flags blocks JBEAP-821 with sufficient flags.

Recent bugclerk runs for jira failed due to JSONException, it seems that Jira sometimes can not return good formatted JSONObject in its response as builds in yesterday are good.

Jenkins job log https://thunder.sin2.redhat.com/jenkins/job/bugclerk-reports-jira-eap70z-unresolved/7512/console

The job is aborted until it's timeout set in Jenkins, But I think it should have some timeout value in BugClerk, so it can actively cancel it in such case.

Low priority. As Jenkins can kill it at 10 mins timeout.

Unlike BZ1160715, a BZ referencing a component upgrade should have link to a fix BZ.

Target release and milestone sanity checks:

• milestone must be present once Issue is in "MODIFIED"
• with exception of component upgrades, milestone pours down once upgrade BZ is in MODIFIED

List of "allowed labels" ? Link a documentation ?

When reporting a violation, Bugclerk should have a more fine grained levels of Severity:

• GREEN, // Severity Level 1, Everything is fine. CP Process is moving forward as planned with no visible obstacles.
• Yellow_GREEN, // Severity Level 2, attention is needed, forward progress can be made.
• YELLOW, // Severity Level 3, A pending condition to Triage.
• ORANGE // Severity Level 4, attention is needed until progress can no longer be made.
• RED; // Severity Level 5, An immediate call to Triage.

Sprint field must match version released. Check query for 7.0.2: https://issues.jboss.org/issues/?filter=12327775

If upgrade JIRA is in sprint X, for version X.x, same must apply to linked issues with category "incorporates" from upgrade JIRA.

Warning is reported on a Doc Fix issue

Bugclerk is completely unusable by downstream projects because it shades in all dependencies.

Get rid of it.

Upstream issue of JBEAP issue should have a label 'downstream_dependency' to ensure we can keep track of them during releases.

(note: ultimately, payload-viewer should be able to display their link next to the JBEAP issue)

Issue: When someone set a BZ to status "POST" it implies a fix has been pushed to Github, therefore a comment on the BZ should feature a PR URL.