-
Notifications
You must be signed in to change notification settings - Fork 0
Update PR data Daily collection (2025-07-28 01:47 UTC) #135
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
Conversation
|
""" WalkthroughThis update advances timestamps and Jenkins build URLs in multiple JSON data files to reflect newer CI runs, moving from July 21, 2025, to July 23, 2025, and incrementing build numbers from 9 to 10. It also reorganizes and corrects metadata in JUnit5 migration PR candidate lists, adjusting order and comments without altering substantive content. Changes
Sequence Diagram(s)sequenceDiagram
participant DataUpdater
participant JSONFiles
participant JenkinsCI
DataUpdater->>JenkinsCI: Fetch latest CI build info (timestamps, URLs)
JenkinsCI-->>DataUpdater: Return updated build number and timestamps
DataUpdater->>JSONFiles: Update CI fields (timestamps, URLs) in JSON data
DataUpdater->>JSONFiles: Reorganize PR candidate metadata as needed
Estimated code review effort🎯 2 (Simple) | ⏱️ ~7 minutes Possibly related PRs
Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (4)
🚧 Files skipped from review as they are similar to previous changes (4)
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
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.
Summary of Changes
Hello @gounthar, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request primarily focuses on maintaining up-to-date data within the repository by automatically refreshing daily statistics and lists. It ensures that the status of failing pull requests and the collection of JUnit5 migration candidates are current, reflecting the latest information from their respective sources.
Highlights
- Automated Data Updates: This pull request is an automated daily update of various data files, ensuring the information is current.
- Failing PRs Status Refresh: The
failing_prs.jsonfile has been updated to reflect the latest status and timestamps for a specific failing pull request (PR-12), indicating a new build attempt or status change. - JUnit5 Migration Candidates List Update: The lists of JUnit5 migration candidate pull requests in both
junit5_candidates.jsonandjunit5_candidate_prs.txthave been refreshed. This includes reordering entries and updating associated metadata such as creation dates, descriptions, and labels for these PRs.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
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.
Code Review
This PR updates several data files with the latest statistics.
My review has identified a few issues:
- Data Correctness: In
data/consolidated/failing_prs.json, there's a logical inconsistency where a check run'scompletedAttimestamp is earlier than itsstartedAttimestamp. This should be investigated to ensure data integrity. - Maintainability: Both
data/junit5/junit5_candidates.jsonandjunit5_candidate_prs.txthave a lot of reordering of entries, which creates noisy diffs and makes it hard to review actual changes. I've suggested sorting the data deterministically (e.g., by URL) in the generation script to address this.
Please take a look at the detailed comments. Addressing the sorting issue will significantly improve the reviewability of future automated PRs.
| "__typename": "CheckRun", | ||
| "completedAt": "2025-07-21T11:35:03Z", | ||
| "completedAt": "2025-07-23T08:41:18Z", | ||
| "conclusion": "FAILURE", | ||
| "detailsUrl": "https://ci.jenkins.io/job/Plugins/job/backup-plugin/job/PR-12/9/display/redirect?page=tests", | ||
| "detailsUrl": "https://ci.jenkins.io/job/Plugins/job/backup-plugin/job/PR-12/10/display/redirect?page=tests", | ||
| "name": "Tests / linux-21 / Build (linux-21)", | ||
| "startedAt": "2025-07-21T11:35:08Z", | ||
| "startedAt": "2025-07-23T08:41:25Z", | ||
| "status": "COMPLETED", | ||
| "workflowName": "" |
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.
There seems to be a logical inconsistency in the timestamps for this CheckRun. The completedAt time (2025-07-23T08:41:18Z) is before the startedAt time (2025-07-23T08:41:25Z).
A check run cannot complete before it has started. This might indicate an issue with the data source or the collection script. Please investigate this to ensure the data integrity.
| { | ||
| "title": "Migrate tests to JUnit5", | ||
| "url": "https://github.com/jenkinsci/digitalocean-plugin/pull/80", | ||
| "repository": "jenkinsci/digitalocean-plugin", | ||
| "url": "https://github.com/jenkinsci/parasoft-findings-plugin/pull/162", | ||
| "repository": "jenkinsci/parasoft-findings-plugin", | ||
| "state": "OPEN", | ||
| "author": "strangelookingnerd", | ||
| "labels": null, | ||
| "body": "This PR aims to migrate all tests to JUnit5. Changes include:\n\nMigrate annotations and imports\nMigrate assertions\nRemove public visibility for test classes and methods\nMinor clean up\n\nI am well aware that this is a quite large changeset however I hope that there is still interest in this PR and it will be reviewed.\nIf there are any questions, please do not hesitate to ping me.\nSubmitter checklist\n\n Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!\n Ensure that the pull request title represents the desired changelog entry\n Please describe what you did\n Link to relevant issues in GitHub or Jira\n Link to relevant pull requests, esp. upstream and downstream changes\n Ensure you have provided tests that demonstrate the feature works or the issue is fixed", | ||
| "createdAt": "2025-06-16T07:48:40Z" | ||
| "body": "This PR aims to migrate all tests to JUnit5. Changes include:\n\nMigrate annotations and imports\nMigrate assertions\nRemove public visibility for test classes and methods\nMinor clean up\n\nI am well aware that this is a quite large changeset however I hope that there is still interest in this PR and it will be reviewed.\nIf there are any questions, please do not hesitate to ping me.\n\n Make sure you are requesting to pull a topic/feature/bugfix branch (right side) and not your master branch!\n Ensure that the pull request title represents the desired changelog entry\n Please describe what you did\n Link to relevant issues in GitHub\n Link to relevant pull requests, esp. upstream and downstream changes\n Ensure you have provided tests - that demonstrates feature works or fixes the issue", | ||
| "createdAt": "2025-05-08T11:59:31Z" | ||
| }, | ||
| { | ||
| "title": "Migrate tests to JUnit5", | ||
| "url": "https://github.com/jenkinsci/parasoft-findings-plugin/pull/162", | ||
| "repository": "jenkinsci/parasoft-findings-plugin", | ||
| "url": "https://github.com/jenkinsci/digitalocean-plugin/pull/80", | ||
| "repository": "jenkinsci/digitalocean-plugin", | ||
| "state": "OPEN", | ||
| "author": "strangelookingnerd", | ||
| "labels": null, | ||
| "body": "This PR aims to migrate all tests to JUnit5. Changes include:\n\nMigrate annotations and imports\nMigrate assertions\nRemove public visibility for test classes and methods\nMinor clean up\n\nI am well aware that this is a quite large changeset however I hope that there is still interest in this PR and it will be reviewed.\nIf there are any questions, please do not hesitate to ping me.\n\n Make sure you are requesting to pull a topic/feature/bugfix branch (right side) and not your master branch!\n Ensure that the pull request title represents the desired changelog entry\n Please describe what you did\n Link to relevant issues in GitHub\n Link to relevant pull requests, esp. upstream and downstream changes\n Ensure you have provided tests - that demonstrates feature works or fixes the issue", | ||
| "createdAt": "2025-05-08T11:59:31Z" | ||
| "body": "This PR aims to migrate all tests to JUnit5. Changes include:\n\nMigrate annotations and imports\nMigrate assertions\nRemove public visibility for test classes and methods\nMinor clean up\n\nI am well aware that this is a quite large changeset however I hope that there is still interest in this PR and it will be reviewed.\nIf there are any questions, please do not hesitate to ping me.\nSubmitter checklist\n\n Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!\n Ensure that the pull request title represents the desired changelog entry\n Please describe what you did\n Link to relevant issues in GitHub or Jira\n Link to relevant pull requests, esp. upstream and downstream changes\n Ensure you have provided tests that demonstrate the feature works or the issue is fixed", | ||
| "createdAt": "2025-06-16T07:48:40Z" | ||
| }, |
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've noticed that many entries in this JSON array are being reordered in this PR. This creates a lot of noise in the diffs, making it difficult to see the actual changes (additions/removals/updates).
For example, the entries for parasoft-findings-plugin and digitalocean-plugin have been swapped. This happens in multiple places in the file.
This is likely because the data is not being sorted deterministically before being written to the file. To improve maintainability and make diffs cleaner, please consider sorting the prs array by a unique and stable key, such as the url.
In the Go script that generates this file, this could be achieved by sorting the slice of pull requests before marshalling it to JSON. For example:
import "sort"
// ...
// Sort by URL for a stable order
sort.Slice(allPRs, func(i, j int) bool {
return allPRs[i].URL < allPRs[j].URL
})This would ensure a consistent order for the entries in the JSON file across runs.
| # jenkinsci/parasoft-findings-plugin - Migrate tests to JUnit5 (OPEN) | ||
| https://github.com/jenkinsci/parasoft-findings-plugin/pull/162 | ||
|
|
||
| # jenkinsci/digitalocean-plugin - Migrate tests to JUnit5 (OPEN) | ||
| https://github.com/jenkinsci/digitalocean-plugin/pull/80 | ||
|
|
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.
Similar to junit5_candidates.json, the entries in this file are being reordered, which creates noisy diffs. For instance, the entries for parasoft-findings-plugin and digitalocean-plugin are swapped here.
This is likely due to a non-deterministic sorting in the generation script. To make changes easier to review, please consider sorting the pull requests before writing them to this file. Sorting by a unique key like the PR URL would be a good approach.
This would ensure a stable order and make it much easier to spot actual additions or removals in future updates.
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.
Actionable comments posted: 3
🧹 Nitpick comments (11)
junit5_candidate_prs.txt (1)
604-606: Duplicate PR entries forjenkinsci/javadoc-plugin– consider deduplicatingLines 598-600 record a merged PR (#186), while these lines register a closed PR (#185). Keeping both may add noise. If historical tracking is not required, remove or consolidate the older record.
data/junit5/junit5_candidates.json (10)
124-142: Prefer[]overnullfor emptylabelsto keep JSON schema uniformOther objects in this list sometimes use an empty array for
labels, while these two usenull.
Down-stream tooling that naïvely assumes a single data type per key may choke on mixednull|arrayvariants.- "labels": null, + "labels": [],Apply the same change to every new/updated record in this patch set.
414-421: Samelabelsnull-vs-array inconsistency
See earlier comment; replacenullwith[]for consistency.
484-501: Body field could be truncated or externalisedThe identical multi-paragraph body string appears in dozens of objects; consider storing a short hash/key here and keeping the verbose text in a separate lookup table to shrink file size by ~80 %.
617-633: Typo in body text
reviewd→reviewed(missing ‘e’).-... it will be reviewd. +... it will be reviewed.
1264-1272: Consistency – use array forlabelsSame recommendation as above.
2053-2061: Large exception note – consider dedicatednoteskeyThe extra paragraph about unmigrated rules is important but conceptually different from the generic body template.
Consider moving these per-PR caveats to anotes(string or array) field so automated consumers can surface them separately.
2144-2163: Label spelling:"tests"vs"test"You use both singular and plural forms across entries. Pick one convention (
"tests"seems most common) to avoid brittle filters.
2203-2210: Closed PR – double-check reasonIf
javadoc-plugin#185was closed without merge, consider capturing a reason (e.g., superseded, abandoned) in an optional field to aid later analysis.
2238-2258: Repeated long body – candidate for deduplicationSame optimisation advice: reference a shared template instead of duplicating >30 lines of boilerplate.
3290-3297: Different author casingAuthor is
CodexRaunak, others are all-lower-case. Confirm if your analytics is case-insensitive; if not, normalise author IDs.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
data/consolidated/all_prs.json(1 hunks)data/consolidated/failing_prs.json(1 hunks)data/consolidated/open_prs.json(1 hunks)data/junit5/junit5_candidates.json(18 hunks)junit5_candidate_prs.txt(14 hunks)
🧰 Additional context used
🧠 Learnings (2)
junit5_candidate_prs.txt (2)
Learnt from: gounthar
PR: gounthar/alpha-omega-stats#0
File: :0-0
Timestamp: 2025-03-07T16:15:13.008Z
Learning: The jenkins-pr-collector should log all PRs found, not just the ones with specific strings like "odernizer" in the body.
Learnt from: gounthar
PR: gounthar/alpha-omega-stats#0
File: :0-0
Timestamp: 2025-03-07T16:15:13.008Z
Learning: For the jenkins-pr-collector tool, all PRs should be logged, not just those with specific keywords like "odernizer" or "recipe" in the body text.
data/junit5/junit5_candidates.json (2)
Learnt from: gounthar
PR: gounthar/alpha-omega-stats#0
File: :0-0
Timestamp: 2025-03-07T16:15:13.008Z
Learning: The jenkins-pr-collector should log all PRs found, not just the ones with specific strings like "odernizer" in the body.
Learnt from: gounthar
PR: gounthar/alpha-omega-stats#0
File: :0-0
Timestamp: 2025-03-07T16:15:13.008Z
Learning: For the jenkins-pr-collector tool, all PRs should be logged, not just those with specific keywords like "odernizer" or "recipe" in the body text.
🔇 Additional comments (25)
data/consolidated/open_prs.json (1)
2035-2040: Jenkins build number & timestamp update looks fineThe bump from build #9 → #10 and the advanced timestamps are internally consistent for this status context/check run.
junit5_candidate_prs.txt (16)
43-45: No issues spotted – entry format & status are consistent
73-75: No issues spotted – entry format & status are consistent
79-81: No issues spotted – entry format & status are consistent
118-120: Multiple open PRs forjenkinsci/jenkins-test-harness– verify intentional duplicationThere is already an open PR for this repo listed at lines 49-51 (
#979). Confirm that keeping both #979 and #988 as separate open items is desired; otherwise the list may look inconsistent.
133-135: No issues spotted – entry format & status are consistent
151-153: No issues spotted – entry format & status are consistent
190-192: No issues spotted – entry format & status are consistent
268-270: No issues spotted – entry format & status are consistent
286-288: No issues spotted – entry format & status are consistent
364-366: No issues spotted – entry format & status are consistent
403-405: No issues spotted – entry format & status are consistent
412-414: No issues spotted – entry format & status are consistent
565-567: No issues spotted – entry format & status are consistent
592-594: No issues spotted – entry format & status are consistent
616-618: No issues spotted – entry format & status are consistent
805-807: No issues spotted – entry format & status are consistentdata/junit5/junit5_candidates.json (8)
225-241: Looks good – no structural issues spotted
URLs, repository identifiers, and timestamps are coherent.
250-262: Entry addition validatedNew AWS Global Configuration plugin record fills a gap (was missing before) and does not duplicate an existing PR.
380-391: Non-migration title still fits dataset scopeThe title “Add JUnit5 equivalents of JUnit4 Rule implementations” deviates from the usual Migrate tests wording but still belongs to JUnit5-migration efforts. Document this in your downstream parser if it relies on strict title matching.
892-908: No action requiredMetadata is correct and consistent; entry transitions state to MERGED properly.
957-976: Mixed label semanticsHere you introduced
"labels": ["java"]. Ensure your analytics distinguishes between semantic labels and test-suite labels so that"java"doesn’t get conflated with"tests"or"chore".
1429-1436: No problems detectedEntry merges fine, timestamp ok.
1470-1478: State CLOSED vs MERGEDFor
oidc-provider-pluginthe state isCLOSED. If the PR was declined rather than merged, good; otherwise confirm whether it was actually merged and adjust state accordingly.
2964-2971: Merged entry OKNo structural issues.
| "completedAt": "2025-07-23T08:41:18Z", | ||
| "conclusion": "FAILURE", | ||
| "detailsUrl": "https://ci.jenkins.io/job/Plugins/job/backup-plugin/job/PR-12/9/display/redirect?page=tests", | ||
| "detailsUrl": "https://ci.jenkins.io/job/Plugins/job/backup-plugin/job/PR-12/10/display/redirect?page=tests", | ||
| "name": "Tests / linux-21 / Build (linux-21)", | ||
| "startedAt": "2025-07-21T11:35:08Z", | ||
| "startedAt": "2025-07-23T08:41:25Z", | ||
| "status": "COMPLETED", |
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.
💡 Verification agent
🧩 Analysis chain
startedAt is after completedAt – timestamps swapped
startedAt (08:41:25Z) must chronologically precede completedAt (08:41:18Z).
This inverted order breaks basic data integrity and can mis-lead any tooling that consumes duration metrics.
- "completedAt": "2025-07-23T08:41:18Z",
+ "completedAt": "2025-07-23T08:41:25Z",
…
- "startedAt": "2025-07-23T08:41:25Z",
+ "startedAt": "2025-07-23T08:41:18Z",Run the quick audit below to catch any other inverted timestamps across all consolidated JSON files:
🏁 Script executed:
#!/bin/bash
# Lists any objects where startedAt > completedAt
for file in data/consolidated/*.json; do
echo "Scanning $file"
jq -r '
.. | objects
| select(has("startedAt") and has("completedAt"))
| select(.startedAt > .completedAt)
| {context: .name // .context, startedAt, completedAt}
' "$file"
doneLength of output: 5063
Let's rerun the audit with a simpler, compatible jq filter to catch any inverted timestamps:
🏁 Script executed:
#!/bin/bash
for file in data/consolidated/*.json; do
echo "Scanning $file"
jq -c '
..
| objects
| select(has("startedAt") and has("completedAt"))
| select(.startedAt > .completedAt)
' "$file" || true
doneLength of output: 209614
Swap inverted timestamps for “Tests / linux-21 / Build (linux-21)” across consolidated JSON
The CheckRun entry for “Tests / linux-21 / Build (linux-21)” has startedAt (08:41:25Z) after completedAt (08:41:18Z). This occurs in three files—please swap them to restore chronological order:
• data/consolidated/all_prs.json
• data/consolidated/failing_prs.json
• data/consolidated/open_prs.json
Apply this patch in each file:
- "completedAt": "2025-07-23T08:41:18Z",
- "startedAt": "2025-07-23T08:41:25Z",
+ "completedAt": "2025-07-23T08:41:25Z",
+ "startedAt": "2025-07-23T08:41:18Z",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "completedAt": "2025-07-23T08:41:18Z", | |
| "conclusion": "FAILURE", | |
| "detailsUrl": "https://ci.jenkins.io/job/Plugins/job/backup-plugin/job/PR-12/9/display/redirect?page=tests", | |
| "detailsUrl": "https://ci.jenkins.io/job/Plugins/job/backup-plugin/job/PR-12/10/display/redirect?page=tests", | |
| "name": "Tests / linux-21 / Build (linux-21)", | |
| "startedAt": "2025-07-21T11:35:08Z", | |
| "startedAt": "2025-07-23T08:41:25Z", | |
| "status": "COMPLETED", | |
| "completedAt": "2025-07-23T08:41:25Z", | |
| "startedAt": "2025-07-23T08:41:18Z", |
🤖 Prompt for AI Agents
In data/consolidated/all_prs.json around lines 2530 to 2535, the CheckRun entry
for "Tests / linux-21 / Build (linux-21)" has the timestamps inverted, with
startedAt occurring after completedAt. Locate this entry and swap the values of
startedAt and completedAt to ensure startedAt is earlier than completedAt.
Repeat the same fix in data/consolidated/failing_prs.json and
data/consolidated/open_prs.json for consistency.
| "completedAt": "2025-07-23T08:41:18Z", | ||
| "conclusion": "FAILURE", | ||
| "detailsUrl": "https://ci.jenkins.io/job/Plugins/job/backup-plugin/job/PR-12/9/display/redirect?page=tests", | ||
| "detailsUrl": "https://ci.jenkins.io/job/Plugins/job/backup-plugin/job/PR-12/10/display/redirect?page=tests", | ||
| "name": "Tests / linux-21 / Build (linux-21)", | ||
| "startedAt": "2025-07-21T11:35:08Z", | ||
| "startedAt": "2025-07-23T08:41:25Z", | ||
| "status": "COMPLETED", |
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.
Inconsistent timestamps: startedAt occurs after completedAt.
startedAt is recorded as 08:41:25Z, which is seven seconds later than completedAt (08:41:18Z). This violates temporal ordering and can break downstream reporting or dashboard logic that assumes start ≤ completion.
- "completedAt": "2025-07-23T08:41:18Z",
...
- "startedAt": "2025-07-23T08:41:25Z",
+ "startedAt": "2025-07-23T08:41:18Z",
+ "completedAt": "2025-07-23T08:41:25Z",Please regenerate or manually correct the data to maintain consistency.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "completedAt": "2025-07-23T08:41:18Z", | |
| "conclusion": "FAILURE", | |
| "detailsUrl": "https://ci.jenkins.io/job/Plugins/job/backup-plugin/job/PR-12/9/display/redirect?page=tests", | |
| "detailsUrl": "https://ci.jenkins.io/job/Plugins/job/backup-plugin/job/PR-12/10/display/redirect?page=tests", | |
| "name": "Tests / linux-21 / Build (linux-21)", | |
| "startedAt": "2025-07-21T11:35:08Z", | |
| "startedAt": "2025-07-23T08:41:25Z", | |
| "status": "COMPLETED", | |
| "startedAt": "2025-07-23T08:41:18Z", | |
| "completedAt": "2025-07-23T08:41:25Z", | |
| "conclusion": "FAILURE", | |
| "detailsUrl": "https://ci.jenkins.io/job/Plugins/job/backup-plugin/job/PR-12/10/display/redirect?page=tests", | |
| "name": "Tests / linux-21 / Build (linux-21)", | |
| "status": "COMPLETED", |
🤖 Prompt for AI Agents
In data/consolidated/failing_prs.json around lines 1137 to 1142, the timestamps
are inconsistent because the startedAt time is after the completedAt time. Fix
this by ensuring that the startedAt timestamp is earlier than or equal to the
completedAt timestamp, either by swapping the values or regenerating the
timestamps to maintain correct temporal order.
| "completedAt": "2025-07-23T08:41:18Z", | ||
| "conclusion": "FAILURE", | ||
| "detailsUrl": "https://ci.jenkins.io/job/Plugins/job/backup-plugin/job/PR-12/9/display/redirect?page=tests", | ||
| "detailsUrl": "https://ci.jenkins.io/job/Plugins/job/backup-plugin/job/PR-12/10/display/redirect?page=tests", | ||
| "name": "Tests / linux-21 / Build (linux-21)", | ||
| "startedAt": "2025-07-21T11:35:08Z", | ||
| "startedAt": "2025-07-23T08:41:25Z", | ||
| "status": "COMPLETED", |
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.
💡 Verification agent
🧩 Analysis chain
startedAt occurs after completedAt – timestamps are reversed
For the “Tests / linux-21 / Build (linux-21)” check run:
"completedAt": "2025-07-23T08:41:18Z",
...
"startedAt": "2025-07-23T08:41:25Z"startedAt (08:41:25) must chronologically precede completedAt (08:41:18). This inverted order breaks temporal consistency and can poison downstream analytics.
Suggested fix (swap the two values or correct at source):
- "completedAt": "2025-07-23T08:41:18Z",
+ "completedAt": "2025-07-23T08:41:25Z",
...
- "startedAt": "2025-07-23T08:41:25Z",
+ "startedAt": "2025-07-23T08:41:18Z",Run the script below to detect any other occurrences where startedAt > completedAt across the dataset:
🏁 Script executed:
#!/bin/bash
# Finds objects where startedAt is later than completedAt
python - << 'PY'
import json, sys, pathlib, datetime, itertools
def iso(t): return datetime.datetime.fromisoformat(t.replace('Z','+00:00'))
fname = "data/consolidated/open_prs.json"
data = json.load(open(fname))
def walk(obj, path=()):
if isinstance(obj, dict):
if 'startedAt' in obj and 'completedAt' in obj:
try:
if iso(obj['startedAt']) > iso(obj['completedAt']):
print(" → ".join(map(str, path)) or "<root>")
except Exception:
pass
for k,v in obj.items():
walk(v, path+(k,))
elif isinstance(obj, list):
for i,v in enumerate(obj):
walk(v, path+(i,))
walk(data)
PYLength of output: 8319
Ensure startedAt always precedes completedAt in your rollup data
A scan of data/consolidated/open_prs.json shows dozens of statusCheckRollup entries where startedAt > completedAt. This isn’t limited to the “Build (linux-21)” run—multiple PRs (e.g. indices 42, 102, 136, …, 362) exhibit inverted timestamps.
To restore temporal consistency and prevent analytics corruption, apply one of the following:
- Fix upstream: correct the source of these events so
startedAtis recorded beforecompletedAt. - Post-process: add a validation step in your ingestion pipeline (or a one-off script) that walks every object with both fields and swaps them when out of order.
Example diff for the originally cited record at lines 2051–2056 in open_prs.json:
- "completedAt": "2025-07-23T08:41:18Z",
+ "completedAt": "2025-07-23T08:41:25Z",
- "startedAt": "2025-07-23T08:41:25Z",
+ "startedAt": "2025-07-23T08:41:18Z",Key locations needing attention:
• data/consolidated/open_prs.json → any statusCheckRollup item where startedAt > completedAt
Please implement the above fix and re-run your validation script to confirm no inverted timestamps remain.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In data/consolidated/open_prs.json around lines 2051 to 2056, there are multiple
statusCheckRollup entries where the startedAt timestamp is later than the
completedAt timestamp, causing temporal inconsistency. To fix this, implement a
validation step in your data ingestion or a one-off script that iterates through
all statusCheckRollup objects, checks if startedAt is greater than completedAt,
and if so, swaps these two timestamps to ensure startedAt always precedes
completedAt. After applying this fix, rerun your validation to confirm no
inverted timestamps remain.
3919eb3 to
eb1bf9d
Compare
eb1bf9d to
d410764
Compare
d410764 to
f79c5aa
Compare
f79c5aa to
d13031a
Compare
This PR contains automatically updated PR statistics data. Generated by GitHub Actions.
Summary by CodeRabbit