Skip to content
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

Merged
merged 26 commits into from
Oct 15, 2024
Merged

ci(server): enhance performance #928

merged 26 commits into from
Oct 15, 2024

Conversation

yk-eukarya
Copy link
Contributor

@yk-eukarya yk-eukarya commented Nov 6, 2023

Summary by CodeRabbit

  • New Features

    • Introduced a new Continuous Integration (CI) workflow to streamline the build process for web, server, and worker components.
    • Added structured checks for pull requests, including title validation and labeling.
  • Bug Fixes

    • Improved job dependencies and execution conditions for enhanced reliability in CI processes.
  • Documentation

    • Updated workflow names and descriptions for clarity.
  • Refactor

    • Restructured CI workflows to utilize workflow_call for better modularity and integration.
    • Enhanced caching strategy for yarn dependencies in the web component workflow.

@yk-eukarya yk-eukarya self-assigned this Nov 6, 2023
@yk-eukarya yk-eukarya requested a review from rot1024 as a code owner November 6, 2023 05:12
Copy link

netlify bot commented Nov 6, 2023

Deploy Preview for reearth-cms canceled.

Name Link
🔨 Latest commit 419a101
🔍 Latest deploy log https://app.netlify.com/sites/reearth-cms/deploys/6709669e03a1fa000803cf84

@github-actions github-actions bot removed the server label Nov 6, 2023
Copy link

codecov bot commented Nov 6, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 49.38%. Comparing base (3a36a1c) to head (f753e65).
Report is 58 commits behind head on main.

❗ Current head f753e65 differs from pull request most recent head 5994a08. Consider uploading reports for the commit 5994a08 to get more accurate results

Additional details and impacted files

Impacted file tree graph

@@            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     
Flag Coverage Δ
server 49.38% <ø> (+2.12%) ⬆️
worker ?

Flags with carried forward coverage won't be shown. Click here to find out more.

see 166 files with indirect coverage changes

@yk-eukarya yk-eukarya marked this pull request as draft November 6, 2023 06:47
# Conflicts:
#	.github/workflows/ci_server.yml
@github-actions github-actions bot added the ci label Mar 8, 2024
@yk-eukarya yk-eukarya marked this pull request as ready for review March 11, 2024 07:04
.github/workflows/ci.yml Outdated Show resolved Hide resolved
.github/workflows/ci.yml Outdated Show resolved Hide resolved
.github/workflows/ci.yml Outdated Show resolved Hide resolved
.github/workflows/ci.yml Outdated Show resolved Hide resolved
.github/workflows/ci_web.yml Show resolved Hide resolved
.github/workflows/ci.yml Show resolved Hide resolved
yk-eukarya and others added 4 commits October 11, 2024 09:48
Co-authored-by: KeisukeYamashita <[email protected]>
Co-authored-by: KeisukeYamashita <[email protected]>
Co-authored-by: KeisukeYamashita <[email protected]>
Co-authored-by: KeisukeYamashita <[email protected]>
Copy link
Contributor

@KeisukeYamashita KeisukeYamashita left a 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
Copy link
Contributor

coderabbitai bot commented Oct 11, 2024

Walkthrough

A new Continuous Integration (CI) workflow has been established in the .github/workflows directory, comprising multiple jobs for web, server, and worker components. The workflows for ci_server, ci_web, and ci_worker have shifted to a workflow_call trigger, enhancing modularity. Additionally, the pr.yml workflow has been updated to include new jobs and event types, improving pull request validation. Overall, these changes aim to streamline the CI process and enhance the structure of the workflows.

Changes

File Path Change Summary
.github/workflows/ci.yml New CI workflow introduced with jobs: prepare, ci-web, ci-server, ci-worker, and ci.
.github/workflows/ci_server.yml Trigger changed to workflow_call; added job ci-server-lint; renamed ci to ci-server-test; updated steps.
.github/workflows/ci_web.yml Trigger changed to workflow_call; updated caching strategy; streamlined job steps.
.github/workflows/ci_worker.yml Trigger changed to workflow_call; added job ci-server-test; renamed ci to ci-server-lint; updated steps.
.github/workflows/pr.yml Workflow name changed to "PR"; added jobs labeler, title_check, and pr_title; updated event types.

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
Loading

🐰 In the garden where we play,
New workflows bloom, bright as day.
With jobs to check and tests to run,
Our CI's now a lot more fun!
Hops and skips, we celebrate,
A smoother path, oh, isn’t it great? 🌼


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?

❤️ 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.
    • Generate unit testing code for this file.
    • 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 generate unit testing code for this file.
    • @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 generate unit testing code.
    • @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.

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

@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

🧹 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:

  1. Add a step to post a summary of all CI results.
  2. Integrate with a notification system to alert relevant team members of successful builds.
  3. 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

📥 Commits

Files that changed from the base of the PR and between c7c79a4 and 794de29.

📒 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 of actions/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:

  1. Comprehensive event triggering for pull requests
  2. Proper labeling job with clear naming
  3. Semantic PR title checking with custom configuration
  4. 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 in setup-node is a good improvement:

  1. It simplifies the workflow by removing manual caching steps.
  2. It leverages the built-in caching mechanism of setup-node, which is typically more efficient.
  3. 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. The setup-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 improvements

The changes to this workflow significantly enhance its modularity and efficiency:

  1. The shift to a workflow_call trigger allows for better integration with other workflows.
  2. The improved caching strategy using setup-node's built-in caching simplifies the workflow and potentially improves performance.
  3. 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 the ci-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:

  1. That there is a parent workflow that correctly calls this ci-web workflow.
  2. 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 the ci.yml workflow. The defined trigger events (push to main and release branches, and pull_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/workflows

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

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

Length of output: 609

.github/workflows/ci_worker.yml (3)

7-8: Review linting job changes and golangci-lint configuration.

  1. The job renaming from 'ci' to 'ci-server-lint' improves clarity about its purpose. This is a good change.

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

  3. 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:

  1. Why was the golangci-lint version downgraded?
  2. 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.yml

This 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' worker

If 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 to any_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:

  1. They depend on the prepare job, ensuring change detection runs first.
  2. They only execute if changes are detected in their respective components, optimizing CI runtime.
  3. 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.

Comment on lines +35 to +42
pr_title:
runs-on: ubuntu-latest
needs:
- labeler
- title_check
if: '!failure()'
steps:
- run: echo OK
Copy link
Contributor

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:

  1. The name pr_title is misleading as this job doesn't actually check the PR title. Consider renaming it to something like pr_checks_passed or pr_validation_complete.

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

.github/workflows/ci_worker.yml Show resolved Hide resolved
.github/workflows/ci_server.yml Show resolved Hide resolved
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: 0

🧹 Outside diff range and nitpick comments (2)
.github/workflows/ci_worker.yml (1)

48-48: Add newline at end of file

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

To 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

📥 Commits

Files that changed from the base of the PR and between 794de29 and 419a101.

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

Update 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 good

The addition of a separate ci-server-test job is a good practice for CI. A few observations:

  1. The 10-minute timeout for tests seems reasonable but may need adjustment based on your project's needs.
  2. The environment variable has changed from REEARTH_CMS_WORKER_DB to REEARTH_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' worker

Also, 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 to workflow_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. The ci_worker.yml workflow is correctly invoked by ci.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/workflows

Length of output: 145


7-8: Improvements to the linting job

The changes to the linting job look good:

  1. Renaming the job to ci-server-lint improves clarity.
  2. Updating golangci-lint to version v1.61 is a good practice.
  3. 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 modularity

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

The introduction of the ci-server-lint job is a great addition to your CI process. It helps maintain code quality by running golangci-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 maintenance

The updates to the ci-server-i18n job are well-structured and valuable. The addition of Go setup and the explicit check for forgotten translations using make i18n-ci will help maintain consistent language support across the project.


41-65: LGTM: Test job improvements enhance reliability and clarity

The updates to the ci-server-test job are well-considered:

  1. Using the GO_VERSION environment variable ensures consistency across jobs.
  2. Adding a 10-minute timeout to the test command prevents potentially hanging tests.
  3. 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 issue

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

@yk-eukarya yk-eukarya enabled auto-merge (squash) October 15, 2024 08:14
@yk-eukarya yk-eukarya disabled auto-merge October 15, 2024 08:14
@yk-eukarya yk-eukarya merged commit 08be04c into main Oct 15, 2024
18 checks passed
@yk-eukarya yk-eukarya deleted the ci/enhance-performance branch October 15, 2024 08:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants