MPT-15317 Report portal setup

[albertsola]

Summary by CodeRabbit

• Chores
  • Optimized CI/CD infrastructure with improved timeout management and resource allocation across automated workflows.
  • Enhanced test environment configuration and reporting integration capabilities.
  • Streamlined build and deployment pipeline processes for improved reliability and efficiency.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

GitHub Actions workflows are updated to increase timeout durations from 20 to 45 minutes across multiple pipelines. ReportPortal integration is added with dynamic launch identifiers derived from GitHub context. A new workflow for release branch pushes is introduced, consolidating build, test, and SonarCloud scanning steps.

Changes

Cohort / File(s)	Summary
Timeout Extension and ReportPortal Updates ​.github/workflows/cron-main-e2e.yml	Increased job timeout-minutes to 45. Changed RP_LAUNCH from static github-e2e-cron-main to dynamic github-e2e-cron-${{ github.ref_name }} for test reporting.
Pull Request Workflow Refactoring ​.github/workflows/pull-request.yml	Removed push triggers for main and release/** branches; workflow now triggers only on pull_request events. Increased timeout to 45 minutes. Added ReportPortal integration flags and environment variables: RP_LAUNCH (dynamic, based on event name and PR/run number), RP_ENDPOINT, and RP_API_KEY sourced from secrets.
New Release Branch Workflow ​.github/workflows/push-release-branch.yml	New workflow triggered on push to main and release/** branches. Includes steps for repository checkout, Docker Compose-based container builds (app_test, e2e targets), environment file creation with MPT/RP variables and secrets, validation and test execution via docker compose, E2E tests with pytest and ReportPortal integration, SonarCloud scan, and container cleanup. Job timeout set to 45 minutes.
Release Workflow Timeout ​.github/workflows/release.yml	Increased job timeout-minutes from 20 to 45.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

• New workflow configuration: Verify .github/workflows/push-release-branch.yml step order, Docker Compose targets, environment variable injection, and secret mapping correctness.
• Dynamic RP_LAUNCH variables: Confirm dynamic variable expressions (${{ github.ref_name }}, ${{ github.event_name }}, etc.) match intended ReportPortal launch naming conventions across workflows.
• Trigger changes: Validate that pull-request.yml removal of push triggers aligns with the new push-release-branch.yml coverage for main and release branches.

Poem

🐰 Workflows now tick and tock with more grace,
Forty-five minutes to finish the race,
ReportPortal launches with names that are bright,
Dynamic and flowing—no static in sight!
Release branches build with a brand-new dance, 🎭✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly aligns with the main objective of the pull request: setting up ReportPortal integration across multiple GitHub Actions workflows.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch MPT-15317/report-portal-setup

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

	Warnings
⚠️	This PR modifies code (4 file(s)) but does not include any changes in the tests/ folder. Please consider adding or updating tests to cover your changes.

✅ Found Jira issue key in the title: MPT-15317

Generated by 🚫 dangerJS against cca24e0

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0699809 and 2c8d642.

📒 Files selected for processing (2)

• .github/workflows/cron-main-e2e.yml (1 hunks)
• .github/workflows/pr-build-merge.yml (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build

🔇 Additional comments (2)

.github/workflows/pr-build-merge.yml (1)

44-44: ReportPortal integration looks correct.

The pytest command with ReportPortal flags is properly structured, and the environment variables are correctly referenced.

.github/workflows/cron-main-e2e.yml (1)

33-33: LGTM! Dynamic launch identifier is appropriate for scheduled workflows.

The use of github.ref_name correctly resolves to the branch name (main) for this cron-triggered workflow, creating a clear and consistent launch identifier: github-e2e-cron-main.

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.github/workflows/release.yml (1)

38-42: Inconsistent RP_LAUNCH value compared to other workflows.

The RP_LAUNCH value is hardcoded to github-e2e-cron-main, which is inconsistent with the dynamic approach used in other workflows. Additionally, the "cron-main" suffix appears incorrect for a release workflow.

Consider using a dynamic identifier similar to other workflows for better traceability:

       env:
-        RP_LAUNCH: github-e2e-cron-main
+        RP_LAUNCH: github-e2e-release-${{ github.ref_name }}
         RP_ENDPOINT: ${{ secrets.RP_ENDPOINT }}
         RP_API_KEY: ${{ secrets.RP_API_KEY }}

🧹 Nitpick comments (1)

.github/workflows/push-release-branch.yml (1)

44-44: Consider using a more descriptive launch identifier pattern.

The current RP_LAUNCH pattern uses github.event.pull_request.number, which will always be undefined for push events, causing it to fall back to github.run_number. While this works, using github.ref_name (similar to cron-main-e2e.yml) would create more descriptive identifiers like github-e2e-push-main or github-e2e-push-release/1.0 instead of github-e2e-push-123.

Apply this diff for better consistency and clarity:

-        RP_LAUNCH: github-e2e-${{ github.event_name }}-${{ github.event.pull_request.number || github.run_number }}
+        RP_LAUNCH: github-e2e-${{ github.event_name }}-${{ github.ref_name }}

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6406c59 and cca24e0.

📒 Files selected for processing (4)

• .github/workflows/cron-main-e2e.yml (2 hunks)
• .github/workflows/pull-request.yml (2 hunks)
• .github/workflows/push-release-branch.yml (1 hunks)
• .github/workflows/release.yml (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build

🔇 Additional comments (6)

.github/workflows/release.yml (1)

15-15: LGTM: Timeout increase aligns with other workflows.

The timeout increase to 45 minutes is consistent with similar changes across other workflows in this PR and provides adequate time for E2E testing.

.github/workflows/cron-main-e2e.yml (2)

9-9: LGTM: Timeout increase aligns with other workflows.

The timeout increase to 45 minutes is consistent with similar changes across other workflows in this PR.

---

33-33: LGTM: Dynamic launch identifier improves traceability.

The dynamic RP_LAUNCH identifier using github.ref_name provides better traceability compared to the previous hardcoded value.

.github/workflows/pull-request.yml (2)

14-14: LGTM: Timeout increase aligns with other workflows.

The timeout increase to 45 minutes is consistent with similar changes across other workflows in this PR.

---

40-44: LGTM: ReportPortal integration properly implemented.

The E2E test now includes ReportPortal integration with a dynamic launch identifier. The conditional expression github.event.pull_request.number || github.run_number provides defensive fallback logic, though it's not strictly necessary since this workflow only triggers on pull_request events.

.github/workflows/push-release-branch.yml (1)

16-16: LGTM: Workflow structure and ReportPortal integration properly implemented.

The workflow correctly:

• Sets an appropriate 45-minute timeout consistent with other workflows
• Builds test containers and creates environment files with necessary secrets
• Runs validation, E2E tests with ReportPortal integration, and SonarCloud scanning
• Ensures cleanup with the always() condition on container shutdown

Also applies to: 24-46, 49-53, 55-57

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Misleading workflow name for push event trigger.

The workflow is named "PR build and merge" but it triggers on push events to main and release/** branches (lines 4-7), not on pull requests. This creates confusion about the workflow's purpose.

Apply this diff to use a more accurate name:

-name: PR build and merge
+name: Push to main/release branches

📝 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

	name: PR build and merge
	name: Push to main/release branches

🤖 Prompt for AI Agents

.github/workflows/push-release-branch.yml lines 1-1: the workflow name "PR build
and merge" is misleading because the workflow triggers on push to main and
release/** branches; update the name to accurately reflect push-triggered
behavior (for example "Push build and release" or "Push build and merge (push)")
by replacing the name value on line 1 with the chosen descriptive title so it
clearly documents the workflow purpose.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud