-
Notifications
You must be signed in to change notification settings - Fork 4
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
ci(server): enhance performance #928
Conversation
✅ Deploy Preview for reearth-cms canceled.
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #928 +/- ##
==========================================
+ Coverage 46.36% 49.38% +3.02%
==========================================
Files 324 211 -113
Lines 22633 16598 -6035
==========================================
- Hits 10493 8197 -2296
+ Misses 11455 7945 -3510
+ Partials 685 456 -229
Flags with carried forward coverage won't be shown. Click here to find out more. |
# Conflicts: # .github/workflows/ci_server.yml
Co-authored-by: KeisukeYamashita <[email protected]>
Co-authored-by: KeisukeYamashita <[email protected]>
Co-authored-by: KeisukeYamashita <[email protected]>
Co-authored-by: KeisukeYamashita <[email protected]>
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.
Thanks for the updates and your explanations!
# Conflicts: # .github/workflows/ci_server.yml # .github/workflows/ci_worker.yml
WalkthroughA new Continuous Integration (CI) workflow has been established in the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CI
participant Web
participant Server
participant Worker
User->>CI: Push to main/release
CI->>CI: Run prepare job
alt Changes detected
CI->>Web: Trigger ci-web job
CI->>Server: Trigger ci-server job
CI->>Worker: Trigger ci-worker job
end
CI->>CI: Run final ci job
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
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.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (7)
.github/workflows/pr.yml (1)
Line range hint
1-9
: Consider using a more descriptive workflow name.The current name "PR" is concise but might be too generic. A more descriptive name could better convey the purpose of this workflow, especially as it now includes multiple checks and actions.
Consider renaming the workflow to something like "PR Validation and Labeling" or "Pull Request Checks". This would more accurately reflect the workflow's expanded functionality.
.github/workflows/ci_worker.yml (1)
44-48
: Approve coverage reporting and fix file formatting.Adding a step to send the coverage report to Codecov is a great practice for maintaining code quality. This change is approved.
There's a minor formatting issue: the file is missing a newline at the end. Please add a newline character at the end of the file to fix this. You can do this by adding an empty line after line 48.
file: coverage.txt +
This ensures the file follows the common convention of ending with a newline character.
🧰 Tools
🪛 yamllint
[error] 48-48: no new line character at the end of file
(new-line-at-end-of-file)
.github/workflows/ci_server.yml (3)
8-24
: Excellent addition of a linting job.The inclusion of a dedicated linting job using
golangci-lint
is a great practice for maintaining code quality. The use of a specific version (v1.55) ensures consistency across different environments.Consider adding a comment explaining why the linter configuration is located in the parent directory (../.golangci.yml). This would help future maintainers understand the setup.
41-65
: Comprehensive test job with good practices.The
ci-server-test
job is well-structured with:
- MongoDB service setup for integration testing
- Thorough test command including race detection and coverage profiling
- 10-minute timeout to prevent hanging tests
- Coverage report sent to Codecov
These are all excellent practices for ensuring code quality and reliability.
Consider adding a step to cache Go modules to speed up the workflow:
- uses: actions/cache@v3 with: path: ~/go/pkg/mod key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }} restore-keys: | ${{ runner.os }}-go-🧰 Tools
🪛 yamllint
[error] 65-65: no new line character at the end of file
(new-line-at-end-of-file)
65-65
: Add a newline at the end of the file.To adhere to common coding standards and prevent potential issues with certain tools, please add a newline character at the end of the file.
🧰 Tools
🪛 yamllint
[error] 65-65: no new line character at the end of file
(new-line-at-end-of-file)
.github/workflows/ci.yml (2)
63-71
: LGTM: Final CI job provides a clear success indicator, with room for enhancement.The final
ci
job effectively serves as an indicator that all component-specific CI jobs have completed successfully. Its dependency on previous jobs and the!failure()
condition ensure it only runs when all checks pass.Consider enhancing this job to provide more value:
- Add a step to post a summary of all CI results.
- Integrate with a notification system to alert relevant team members of successful builds.
- Trigger downstream processes that depend on successful CI completion, if applicable.
Example enhancement:
ci: runs-on: ubuntu-latest needs: - ci-web - ci-server - ci-worker if: '!failure()' steps: - name: Post CI summary run: | echo "## CI Summary" >> $GITHUB_STEP_SUMMARY echo "✅ All CI checks passed successfully" >> $GITHUB_STEP_SUMMARY - name: Notify team uses: 8398a7/action-slack@v3 with: status: ${{ job.status }} text: 'CI completed successfully for PR #${{ github.event.pull_request.number }}' env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}🧰 Tools
🪛 yamllint
[error] 71-71: no new line character at the end of file
(new-line-at-end-of-file)
71-71
: Minor: Add newline at end of file.To adhere to YAML best practices and resolve the yamllint warning, please add a newline character at the end of the file.
ci: runs-on: ubuntu-latest needs: - ci-web - ci-server - ci-worker if: '!failure()' steps: - run: echo OK +
🧰 Tools
🪛 yamllint
[error] 71-71: no new line character at the end of file
(new-line-at-end-of-file)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (5)
- .github/workflows/ci.yml (1 hunks)
- .github/workflows/ci_server.yml (1 hunks)
- .github/workflows/ci_web.yml (2 hunks)
- .github/workflows/ci_worker.yml (1 hunks)
- .github/workflows/pr.yml (3 hunks)
🧰 Additional context used
🪛 yamllint
.github/workflows/ci.yml
[error] 71-71: no new line character at the end of file
(new-line-at-end-of-file)
.github/workflows/ci_server.yml
[error] 65-65: no new line character at the end of file
(new-line-at-end-of-file)
.github/workflows/ci_worker.yml
[error] 48-48: no new line character at the end of file
(new-line-at-end-of-file)
🔇 Additional comments (14)
.github/workflows/pr.yml (3)
11-17
: LGTM: Labeler job is well-configured.The renaming of the job to
labeler
and the use ofactions/labeler@v5
are appropriate. The configuration looks correct and follows best practices for automatic PR labeling.
Line range hint
1-42
: Overall, the PR workflow improvements are commendable.The changes to this workflow file have significantly enhanced its functionality and structure. The addition of semantic PR title checking and the reorganization of jobs provide a more robust PR validation process. Here's a summary of the improvements:
- Comprehensive event triggering for pull requests
- Proper labeling job with clear naming
- Semantic PR title checking with custom configuration
- Final validation job to ensure all checks pass
These changes will contribute to maintaining code quality and consistency in the project. The suggestions provided in the review comments, if implemented, will further refine the workflow's clarity and effectiveness.
Line range hint
18-34
: LGTM: Title check job is well-configured, but clarification needed.The addition of a semantic PR title check using
amannn/action-semantic-pull-request@v5
is a good practice. The configuration looks comprehensive, including custom scopes and patterns.Could you clarify the purpose of the
ignoreLabels: meta
option? It's not immediately clear what type of PRs this is intended to exclude from the title check.To verify the usage of the "meta" label, let's run the following script:
This will help us understand if the "meta" label is consistently used across the repository.
.github/workflows/ci_web.yml (4)
16-17
: Approve new caching strategy and address past concerns.The new caching strategy using the
cache
option insetup-node
is a good improvement:
- It simplifies the workflow by removing manual caching steps.
- It leverages the built-in caching mechanism of
setup-node
, which is typically more efficient.- The
cache-dependency-path
ensures correct caching in monorepo setups.Regarding the past review comment about branch-specific caching:
This new approach typically shares caches across branches, addressing the previous concern. Thesetup-node
action's caching is designed to work well in most CI scenarios, including cross-branch cache sharing when appropriate.
12-12
: Approve checkout step reordering.Moving the checkout step earlier in the workflow is a good practice. It ensures that the repository is available for all subsequent steps, improving the logical flow of the workflow.
Line range hint
1-44
: Summary of CI workflow improvementsThe changes to this workflow significantly enhance its modularity and efficiency:
- The shift to a
workflow_call
trigger allows for better integration with other workflows.- The improved caching strategy using
setup-node
's built-in caching simplifies the workflow and potentially improves performance.- The reordering of steps, particularly moving the checkout step earlier, improves the logical flow.
These changes align well with the PR objectives of enhancing CI performance and structure. They should contribute to a more maintainable and efficient CI process for the web component.
3-3
: Approve workflow trigger change, but verify integration.The change to
workflow_call
aligns with the goal of enhancing modularity in the CI process. This allows theci-web
workflow to be called by other workflows, potentially improving organization and reusability.To ensure this change doesn't negatively impact the CI process for the web component, please verify:
- That there is a parent workflow that correctly calls this
ci-web
workflow.- That the parent workflow is triggered appropriately for all necessary events (e.g., pushes, pull requests) related to the web component.
Run the following script to check for workflows that might be calling this one:
✅ Verification successful
CI Workflow Integration Verified
The
ci-web
workflow is correctly integrated and invoked by theci.yml
workflow. The defined trigger events (push
tomain
andrelease
branches, andpull_request
) ensure that the CI process for the web component functions as intended.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for workflows that might be calling ci_web.yml # Test: Search for workflows that might be calling ci_web.yml rg --type yaml 'uses: ./.github/workflows/ci_web.yml' .github/workflowsLength of output: 139
Script:
#!/bin/bash # Description: Extract trigger events from ci.yml to verify CI triggers # Extract the 'on' section from ci.yml with context rg -A 10 '^on:' .github/workflows/ci.ymlLength of output: 316
Script:
#!/bin/bash # Description: Extract the 'jobs' section from ci.yml to verify integration with ci_web.yml # Extract the 'jobs' section with context rg -A 20 '^jobs:' .github/workflows/ci.ymlLength of output: 609
.github/workflows/ci_worker.yml (3)
7-8
: Review linting job changes and golangci-lint configuration.
The job renaming from 'ci' to 'ci-server-lint' improves clarity about its purpose. This is a good change.
The golangci-lint version has been downgraded from v1.61 to v1.55. This is unusual as it's generally better to use the latest version for improved linting capabilities.
The 'skip-cache: true' option has been added to the golangci-lint step. This might increase the execution time of the workflow, as it prevents caching of golangci-lint results.
Could you please clarify:
- Why was the golangci-lint version downgraded?
- Is there a specific reason for skipping the cache in the golangci-lint step?
To check if there are any compatibility issues with the latest golangci-lint version, you can run:
#!/bin/bash # Description: Check golangci-lint version compatibility # Test: Run golangci-lint with the latest version docker run --rm -v $(pwd):/app -w /app golangci/golangci-lint:latest golangci-lint run --config=.golangci.ymlThis will help determine if there are any issues preventing the use of the latest version.
Also applies to: 20-23
24-43
: Approve new test job and verify environment variable usage.The addition of a separate 'ci-server-test' job is a good practice for separation of concerns. The configuration looks appropriate, including the MongoDB service and the 10-minute timeout for tests.
To ensure the environment variable change doesn't break any existing code, please run the following script:
#!/bin/bash # Description: Check for uses of the old environment variable name # Test: Search for references to the old environment variable name rg 'REEARTH_CMS_WORKER_DB' workerIf any results are found, make sure to update those references to use the new
REEARTH_CMS_DB
environment variable name.Additionally, monitor the test execution times to ensure the 10-minute timeout is sufficient. If tests frequently approach this limit, consider increasing it or optimizing the tests.
3-3
: Approve workflow trigger change and verify usage.The change to
workflow_call
enhances modularity and allows for better orchestration of CI processes. This aligns well with the PR objective of enhancing performance.To ensure this workflow is being utilized, please run the following script to check for references to this workflow in other workflow files:
If no results are found, ensure that this workflow is indeed being called from another workflow, or it may never run.
.github/workflows/ci_server.yml (1)
25-40
: Well-structured i18n check job.The
ci-server-i18n
job is well-organized and includes necessary steps for checking forgotten translations. Using a Makefile command (make i18n-ci
) is a good practice for centralizing project tasks..github/workflows/ci.yml (3)
1-5
: LGTM: Workflow name and trigger events are well-defined.The workflow name "ci" is concise and appropriate. The trigger events cover the main scenarios where CI should run: pushes to main and release branches, and pull requests. This ensures that the CI process is executed for all relevant code changes.
7-44
: LGTM: Prepare job is well-structured, with a minor suggestion.The prepare job efficiently determines which components have changed using the tj-actions/changed-files action. It correctly includes relevant workflow files in the change detection for each component.
As suggested in a previous review, consider changing
any_changed
toany_modified
in the job outputs:outputs: web: ${{ steps.web.outputs.any_modified }} server: ${{ steps.server.outputs.any_modified }} worker: ${{ steps.worker.outputs.any_modified }}This change will ensure that file deletions are also detected, providing more comprehensive change tracking.
45-61
: LGTM: Component-specific CI jobs are well-structured and efficient.The ci-web, ci-server, and ci-worker jobs are efficiently designed:
- They depend on the prepare job, ensuring change detection runs first.
- They only execute if changes are detected in their respective components, optimizing CI runtime.
- They use separate workflow files (ci_web.yml, ci_server.yml, ci_worker.yml), promoting modularity and easier maintenance.
This structure allows for independent evolution of CI processes for each component while maintaining an integrated workflow.
pr_title: | ||
runs-on: ubuntu-latest | ||
needs: | ||
- labeler | ||
- title_check | ||
if: '!failure()' | ||
steps: | ||
- run: echo OK |
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.
🛠️ Refactor suggestion
Suggest improvements for the pr_title
job.
While the job serves as a final check, there are a few points to consider:
-
The name
pr_title
is misleading as this job doesn't actually check the PR title. Consider renaming it to something likepr_checks_passed
orpr_validation_complete
. -
The echo command doesn't provide much value. Consider adding more informative output or removing the job entirely if it's not performing any significant action.
Here's a suggested improvement:
pr_validation_complete:
runs-on: ubuntu-latest
needs:
- labeler
- title_check
if: success()
steps:
- name: PR Validation Passed
run: |
echo "All PR checks have passed successfully:"
echo "- Labeling completed"
echo "- Title format validated"
This change provides more meaningful output and accurately represents the job's purpose.
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: 0
🧹 Outside diff range and nitpick comments (2)
.github/workflows/ci_worker.yml (1)
48-48
: Add newline at end of fileThe YAML linter has detected that there's no newline character at the end of the file. While this is a minor issue, it's good practice to end files with a newline.
Please add a newline at the end of the file. You can do this by adding an empty line at the end of the file.
🧰 Tools
🪛 yamllint
[error] 48-48: no new line character at the end of file
(new-line-at-end-of-file)
.github/workflows/ci_server.yml (1)
65-65
: Add a newline at the end of the fileTo adhere to YAML style guidelines and improve consistency, please add a newline character at the end of the file.
Apply this change:
file: coverage.txt +
🧰 Tools
🪛 yamllint
[error] 65-65: no new line character at the end of file
(new-line-at-end-of-file)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
- .github/workflows/ci_server.yml (1 hunks)
- .github/workflows/ci_worker.yml (1 hunks)
🧰 Additional context used
🪛 yamllint
.github/workflows/ci_server.yml
[error] 65-65: no new line character at the end of file
(new-line-at-end-of-file)
.github/workflows/ci_worker.yml
[error] 48-48: no new line character at the end of file
(new-line-at-end-of-file)
🔇 Additional comments (9)
.github/workflows/ci_worker.yml (4)
4-5
:⚠️ Potential issueUpdate Go version to a valid, stable release
The
GO_VERSION
environment variable is set to "1.23", which is not a valid Go version. As of October 2024, the latest stable version of Go is 1.21.x, with 1.22 expected to be released in February 2024.Please update the Go version to a valid, stable release. For example:
- GO_VERSION: "1.23" + GO_VERSION: "1.21.3"Alternatively, if you intend to use the latest version, consider using "1.22" once it's released.
24-48
: New ci-server-test job looks goodThe addition of a separate
ci-server-test
job is a good practice for CI. A few observations:
- The 10-minute timeout for tests seems reasonable but may need adjustment based on your project's needs.
- The environment variable has changed from
REEARTH_CMS_WORKER_DB
toREEARTH_CMS_DB
.Please ensure that the new environment variable
REEARTH_CMS_DB
is correctly used in the worker code. You can verify this with the following command:#!/bin/bash # Description: Check for the usage of the new environment variable in the worker code # Test: Search for both old and new environment variable names echo "Old environment variable usage:" rg 'REEARTH_CMS_WORKER_DB' worker echo "New environment variable usage:" rg 'REEARTH_CMS_DB' workerAlso, monitor the duration of the test job in the next few runs to ensure the 10-minute timeout is appropriate.
🧰 Tools
🪛 yamllint
[error] 48-48: no new line character at the end of file
(new-line-at-end-of-file)
3-3
: Workflow trigger updated toworkflow_call
The change to use
workflow_call
as the trigger indicates a shift towards a more modular workflow design. This can improve reusability and maintainability of the CI process.Please ensure that this workflow is properly called from other workflows to maintain the desired CI coverage. You can verify this with the following script:
✅ Verification successful
Workflow trigger updated to
workflow_call
The change to use
workflow_call
as the trigger has been verified and is functioning as intended. Theci_worker.yml
workflow is correctly invoked byci.yml
, ensuring the CI process remains intact and modular.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if the ci_worker workflow is called from other workflows # Test: Search for workflow calls to ci_worker rg --type yaml 'uses: ./.github/workflows/ci_worker.yml' .github/workflowsLength of output: 145
7-8
: Improvements to the linting jobThe changes to the linting job look good:
- Renaming the job to
ci-server-lint
improves clarity.- Updating
golangci-lint
to versionv1.61
is a good practice.- Adding the
skip-cache: true
option ensures fresh results but might impact performance.To ensure the
skip-cache
option doesn't significantly slow down your CI process, you may want to compare the job duration before and after this change. You can use the following GitHub CLI command to check the workflow run times:Also applies to: 17-23
.github/workflows/ci_server.yml (5)
3-3
: LGTM: Workflow trigger updated for improved modularityThe change to
workflow_call
trigger is a good practice. It allows this workflow to be called by other workflows, enhancing the overall modularity and reusability of your CI process.
8-24
: LGTM: Addition of linting job enhances code quality checksThe introduction of the
ci-server-lint
job is a great addition to your CI process. It helps maintain code quality by runninggolangci-lint
. The explicit specification of the linter version, working directory, and config file location ensures consistency across different environments.
25-40
: LGTM: Enhanced i18n checks improve language support maintenanceThe updates to the
ci-server-i18n
job are well-structured and valuable. The addition of Go setup and the explicit check for forgotten translations usingmake i18n-ci
will help maintain consistent language support across the project.
41-65
: LGTM: Test job improvements enhance reliability and clarityThe updates to the
ci-server-test
job are well-considered:
- Using the
GO_VERSION
environment variable ensures consistency across jobs.- Adding a 10-minute timeout to the test command prevents potentially hanging tests.
- Renaming the coverage report step to "Send coverage report" improves clarity.
These changes contribute to a more robust and maintainable CI process.
🧰 Tools
🪛 yamllint
[error] 65-65: no new line character at the end of file
(new-line-at-end-of-file)
4-5
:⚠️ Potential issueUpdate the Go version to a valid, stable release
The
GO_VERSION
is set to "1.23", which is not a valid Go version. As of October 2024, the latest stable version is 1.21.Consider updating the Go version to a valid, stable release:
- GO_VERSION: "1.23" + GO_VERSION: "1.21"
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Refactor
workflow_call
for better modularity and integration.