Skip to content

Conversation

@gounthar
Copy link
Owner

@gounthar gounthar commented Jul 24, 2025

This PR contains automatically updated PR statistics data. Generated by GitHub Actions.

Summary by CodeRabbit

  • Chores
    • Updated timestamps and build numbers for continuous integration status checks and check runs on several pull requests.
    • Adjusted and reorganized metadata for JUnit5 migration pull request candidates, including URLs, repositories, creation dates, and descriptions.
    • Added and reordered entries in the JUnit5 migration candidate list, including new plugin candidates and updated comment formatting.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jul 24, 2025

"""

Walkthrough

This 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

Files/Groups Change Summary
data/consolidated/all_prs.json
data/consolidated/failing_prs.json
data/consolidated/open_prs.json
Updated CI-related timestamps and Jenkins build URLs from July 21, 2025 (build 9) to July 23, 2025 (build 10).
data/junit5/junit5_candidates.json Swapped URLs, repositories, dates, and bodies among entries; added/removed entries for accuracy; minor text edits.
junit5_candidate_prs.txt Updated timestamp comment; reordered and toggled comment state for several plugin PR entries; no 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
Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~7 minutes

Possibly related PRs

Poem

Another day, another run,
CI builds march, never done!
Timestamps leap and numbers grow,
Jenkins hums with status flow.
PR lists shuffled, neat and bright—
A rabbit hops with pure delight!
🐇✨
"""

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f79c5aa and d13031a.

📒 Files selected for processing (4)
  • data/consolidated/all_prs.json (3 hunks)
  • data/consolidated/failing_prs.json (1 hunks)
  • data/consolidated/open_prs.json (1 hunks)
  • junit5_candidate_prs.txt (26 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
  • data/consolidated/all_prs.json
  • data/consolidated/open_prs.json
  • data/consolidated/failing_prs.json
  • junit5_candidate_prs.txt
✨ Finishing Touches
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch auto-update-pr-data

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.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need 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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a 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.json file 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.json and junit5_candidate_prs.txt have 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

  1. 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.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a 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's completedAt timestamp is earlier than its startedAt timestamp. This should be investigated to ensure data integrity.
  • Maintainability: Both data/junit5/junit5_candidates.json and junit5_candidate_prs.txt have 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.

Comment on lines 1136 to 1143
"__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": ""
Copy link
Contributor

Choose a reason for hiding this comment

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

high

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.

Comment on lines 123 to 142
{
"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"
},
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

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.

Comment on lines 40 to 45
# 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

Copy link
Contributor

Choose a reason for hiding this comment

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

medium

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.

Copy link
Contributor

@coderabbitai coderabbitai bot left a 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 for jenkinsci/javadoc-plugin – consider deduplicating

Lines 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 [] over null for empty labels to keep JSON schema uniform

Other objects in this list sometimes use an empty array for labels, while these two use null.
Down-stream tooling that naïvely assumes a single data type per key may choke on mixed null|array variants.

-      "labels": null,
+      "labels": [],

Apply the same change to every new/updated record in this patch set.


414-421: Same labels null-vs-array inconsistency
See earlier comment; replace null with [] for consistency.


484-501: Body field could be truncated or externalised

The 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

reviewdreviewed (missing ‘e’).

-... it will be reviewd.
+... it will be reviewed.

1264-1272: Consistency – use array for labels

Same recommendation as above.


2053-2061: Large exception note – consider dedicated notes key

The extra paragraph about unmigrated rules is important but conceptually different from the generic body template.
Consider moving these per-PR caveats to a notes (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 reason

If javadoc-plugin#185 was 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 deduplication

Same optimisation advice: reference a shared template instead of duplicating >30 lines of boilerplate.


3290-3297: Different author casing

Author 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

📥 Commits

Reviewing files that changed from the base of the PR and between 793eb0b and 3919eb3.

📒 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 fine

The 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 for jenkinsci/jenkins-test-harness – verify intentional duplication

There 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 consistent

data/junit5/junit5_candidates.json (8)

225-241: Looks good – no structural issues spotted
URLs, repository identifiers, and timestamps are coherent.


250-262: Entry addition validated

New 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 scope

The 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 required

Metadata is correct and consistent; entry transitions state to MERGED properly.


957-976: Mixed label semantics

Here 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 detected

Entry merges fine, timestamp ok.


1470-1478: State CLOSED vs MERGED

For oidc-provider-plugin the state is CLOSED. If the PR was declined rather than merged, good; otherwise confirm whether it was actually merged and adjust state accordingly.


2964-2971: Merged entry OK

No structural issues.

Comment on lines +2530 to 2535
"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",
Copy link
Contributor

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"
done

Length 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
done

Length 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.

Suggested change
"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.

Comment on lines +1137 to 1142
"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",
Copy link
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue

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.

Suggested change
"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.

Comment on lines +2051 to 2056
"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",
Copy link
Contributor

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)
PY

Length 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 startedAt is recorded before completedAt.
  • 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.

@gounthar gounthar changed the title Update PR data Daily collection (2025-07-24 01:45 UTC) Update PR data Daily collection (2025-07-25 01:45 UTC) Jul 25, 2025
@gounthar gounthar force-pushed the auto-update-pr-data branch from 3919eb3 to eb1bf9d Compare July 25, 2025 01:45
@gounthar gounthar changed the title Update PR data Daily collection (2025-07-25 01:45 UTC) Update PR data Daily collection (2025-07-26 01:43 UTC) Jul 26, 2025
@gounthar gounthar force-pushed the auto-update-pr-data branch from eb1bf9d to d410764 Compare July 26, 2025 01:43
@gounthar gounthar changed the title Update PR data Daily collection (2025-07-26 01:43 UTC) Update PR data Daily collection (2025-07-27 01:47 UTC) Jul 27, 2025
@gounthar gounthar force-pushed the auto-update-pr-data branch from d410764 to f79c5aa Compare July 27, 2025 01:47
@gounthar gounthar changed the title Update PR data Daily collection (2025-07-27 01:47 UTC) Update PR data Daily collection (2025-07-28 01:47 UTC) Jul 28, 2025
@gounthar gounthar force-pushed the auto-update-pr-data branch from f79c5aa to d13031a Compare July 28, 2025 01:47
@gounthar gounthar merged commit a4720b6 into main Jul 28, 2025
7 checks passed
@gounthar gounthar deleted the auto-update-pr-data branch July 28, 2025 13:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants