chore: Trigger TBP on pg for scheduled run on release #36399
Conversation
WalkthroughThe recent changes involve modifications to GitHub Actions workflows, particularly in the handling of PostgreSQL builds. The Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
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
Documentation and Community
|
github-actions
bot
added
the
skip-changelog
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Outside diff range and nitpick comments (1)
.github/workflows/test-build-docker-image.yml (1)
62-68: Great job introducing a structured approach for handling releases!The new
invoke-tbp-workflow-for-pgjob is a clever way to dispatch another workflow specifically for thepgbranch during release events. The job is correctly conditioned to run only for non-push events on thereleasebranch, ensuring it doesn't interfere with regular builds.However, please update the reusable workflow call at line 65 to follow the format
owner/repo/path/to/workflow.yml@refor./path/to/workflow.ymlas per GitHub Actions best practices. This will make the workflow more maintainable and easier to understand.Tools
actionlint
65-65: reusable workflow call "benc-uk/workflow-dispatch@v1" at "uses" is not following the format "owner/repo/path/to/workflow.yml@ref" nor "./path/to/workflow.yml". see https://docs.github.com/en/actions/learn-github-actions/reusing-workflows for more details
(workflow-call)
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files selected for processing (2)
- .github/workflows/build-docker-image.yml (0 hunks)
- .github/workflows/test-build-docker-image.yml (4 hunks)
Files not reviewed due to no reviewable changes (1)
- .github/workflows/build-docker-image.yml
Additional context used
actionlint
.github/workflows/test-build-docker-image.yml
65-65: reusable workflow call "benc-uk/workflow-dispatch@v1" at "uses" is not following the format "owner/repo/path/to/workflow.yml@ref" nor "./path/to/workflow.yml". see https://docs.github.com/en/actions/learn-github-actions/reusing-workflows for more details
(workflow-call)
129-129: input "skip-tests" is typed as string by reusable workflow "./.github/workflows/server-build.yml". bool value cannot be assigned
(expression)
130-130: input "is-pg-build" is typed as string by reusable workflow "./.github/workflows/server-build.yml". bool value cannot be assigned
(expression)
Additional comments not posted (4)
.github/workflows/test-build-docker-image.yml (4)
26-26: Excellent work simplifying the workflow!By limiting the
pushevent to only trigger actions for themasterbranch, you have streamlined the workflow and reduced unnecessary builds. This change is logical and well-implemented.
111-111: Nicely done focusing the CI processes on themasterbranch!By updating the condition for the
ci-testjob to only execute for non-push events or themasterbranch, you have further streamlined the testing and deployment pipeline. This change aligns well with the overall workflow simplification strategy.
124-124: Good job maintaining consistency in the CI processes!Updating the condition for the
server-unit-testsjob to only execute for non-push events or themasterbranch is consistent with the changes made to theci-testjob. This further streamlines the testing pipeline and maintains a clear focus on themasterbranch.
135-135: Excellent work maintaining a consistent CI strategy!Updating the condition for the
client-unit-testsjob to only execute for non-push events or themasterbranch is in line with the changes made to the other CI jobs. This maintains a consistent focus on themasterbranch and further streamlines the testing pipeline.
| skip-tests: false | ||
| is-pg-build: ${{ github.ref == 'refs/heads/pg' }} |
There was a problem hiding this comment.
Oops! It looks like there's a type mismatch in the reusable workflow inputs.
The skip-tests and is-pg-build inputs are being assigned boolean values, but the reusable workflow ./.github/workflows/server-build.yml expects these inputs to be of type string. This mismatch can lead to unexpected behavior or errors in the server-unit-tests job.
To fix this issue, you should convert the boolean values to strings before passing them to the reusable workflow. For example:
with:
skip-tests: ${{ false }}
is-pg-build: ${{ github.ref == 'refs/heads/pg' }}Would you like me to open a GitHub issue to track this task, or do you want to make the changes yourself?
Tools
actionlint
129-129: input "skip-tests" is typed as string by reusable workflow "./.github/workflows/server-build.yml". bool value cannot be assigned
(expression)
130-130: input "is-pg-build" is typed as string by reusable workflow "./.github/workflows/server-build.yml". bool value cannot be assigned
(expression)
) ## Description We want to trigger TBP workflow on pg on a scheduled basis similar to what we have for release branch to be aware of failures on pg branch because of the continuous merges from release. We searched if scheduled job can be triggered for non default branch but that is not possible. With this PR we are adding a job in the workflow to trigger the `workflow_dispatch` event with ref to pg branch. Other options which we may want to explore is [reusable workflows](https://docs.github.com/en/actions/sharing-automations/reusing-workflows). /test sanity ### 🔍 Cypress test results <!-- This is an auto-generated comment: Cypress test results --> > [!CAUTION] > If you modify the content in this section, you are likely to disrupt the CI result for your PR. <!-- end of auto-generated comment: Cypress test results --> ## Communication Should the DevRel and Marketing teams inform users about this change? - [ ] Yes - [x] No <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Introduced a new job for handling PostgreSQL workflows during release events. - **Changes** - Removed the `is-pg-build` parameter from the build workflow. - Simplified the CI process by limiting job triggers to the `master` branch. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Description
We want to trigger TBP workflow on pg on a scheduled basis similar to what we have for release branch to be aware of failures on pg branch because of the continuous merges from release. We searched if scheduled job can be triggered for non default branch but that is not possible. With this PR we are adding a job in the workflow to trigger the
workflow_dispatchevent with ref to pg branch. Other options which we may want to explore is reusable workflows./test sanity
🔍 Cypress test results
Caution
If you modify the content in this section, you are likely to disrupt the CI result for your PR.
Communication
Should the DevRel and Marketing teams inform users about this change?
Summary by CodeRabbit
is-pg-buildparameter from the build workflow.masterbranch.