[ci]: cancel previous CI run in case of new commit/push

[navin772]

User description

🔗 Related Issues

💥 What does this PR do?

Cancels previous CI run when there is a new commit in the same PR/branch using gh actions concurrency.
This should free up resources and block unnecessary runs.
https://docs.github.com/en/enterprise-cloud@latest/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency

I added this to only those CI which are resource intensive and takes longer to execute.

🔧 Implementation Notes

💡 Additional Considerations

We need to decide if this is safe for every scenario for selenium, as far as I see, it shouldn't cause any issues, if it does we can revert this PR.

🔄 Types of changes

• Cleanup (formatting, renaming)

---

PR Type

Enhancement

---

Description

• Add GitHub Actions concurrency to cancel previous CI runs

• Prevents duplicate workflow executions on new commits

• Frees up resources by stopping redundant builds

• Applied to all language-specific CI workflows

---

Diagram Walkthrough

flowchart LR
  A["New Commit/Push"] -->|triggers| B["GitHub Actions Workflow"]
  B -->|concurrency group| C["Cancel Previous Run"]
  C -->|frees resources| D["Efficient CI Execution"]

Loading

File Walkthrough

Relevant files

Configuration changes

ci-dotnet.yml Add concurrency configuration to dotnet CI                              .github/workflows/ci-dotnet.yml Added concurrency configuration block Groups workflows by workflow name and PR number or ref Enables automatic cancellation of in-progress runs +4/-0      ci-java.yml Add concurrency configuration to java CI                                  .github/workflows/ci-java.yml Added concurrency configuration block Groups workflows by workflow name and PR number or ref Enables automatic cancellation of in-progress runs +4/-0      ci-python.yml Add concurrency configuration to python CI                              .github/workflows/ci-python.yml Added concurrency configuration block Groups workflows by workflow name and PR number or ref Enables automatic cancellation of in-progress runs +4/-0      ci-rbe.yml Add concurrency configuration to RBE CI                                    .github/workflows/ci-rbe.yml Added concurrency configuration block Groups workflows by workflow name and PR number or ref Enables automatic cancellation of in-progress runs +4/-0      ci-ruby.yml Add concurrency configuration to ruby CI                                  .github/workflows/ci-ruby.yml Added concurrency configuration block Groups workflows by workflow name and PR number or ref Enables automatic cancellation of in-progress runs +4/-0      ci-rust.yml Add concurrency configuration to rust CI                                  .github/workflows/ci-rust.yml Added concurrency configuration block Groups workflows by workflow name and PR number or ref Enables automatic cancellation of in-progress runs +4/-0      ci.yml Add concurrency configuration to main CI                                  .github/workflows/ci.yml Added concurrency configuration block Groups workflows by workflow name and PR number or ref Enables automatic cancellation of in-progress runs +4/-0

---

[qodo-merge-pro]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟡	🎫 #5678 🔴 Investigate and resolve "Error: ConnectFailure (Connection refused)" occurring when instantiating multiple ChromeDriver instances on Ubuntu 16.04 with Selenium 3.9.0, Chrome 65, and ChromeDriver 2.35. Ensure subsequent ChromeDriver instantiations do not produce the connection error, while the first also remains stable. Provide a fix or guidance that prevents the error from recurring in CI or local environments.
🟡	🎫 #1234 🔴 Restore behavior where WebDriver click() triggers JavaScript in link href for Firefox 42 with Selenium 2.48.x, matching 2.47.1 behavior. Provide regression test or verification that alert is triggered as in provided test case.
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-merge-pro]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	✅ Prevent unintended workflow cancellations Suggestion Impact: The concurrency group was updated to add `${{ github.event_name }}` between the workflow name and the PR/ref, matching the suggested change. code diff: concurrency: - group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} + group: ${{ github.workflow }}-${{ github.event_name }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: true To prevent unintended cancellations between scheduled and push-triggered workflows, update the concurrency group to include the event type by adding ${{ github.event_name }}. .github/workflows/ci.yml [13-15] concurrency: - group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} + group: ${{ github.workflow }}-${{ github.event_name }}-${{ github.event.pull_request.number || github.ref }} cancel-in-progress: true [Suggestion processed] Suggestion importance[1-10]: 8 __ Why: The suggestion correctly identifies a subtle but important issue where scheduled and push-triggered workflows would cancel each other, and the proposed fix using ${{ github.event_name }} is the correct solution.	Medium
Update

[navin772]

Suggestion by the AI bot to group on basis of event_name sounds good, should I apply it?