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: add some checks in the github action #213

Merged
merged 2 commits into from
Dec 12, 2024

Conversation

daviderli614
Copy link
Member

@daviderli614 daviderli614 commented Dec 11, 2024

Summary by CodeRabbit

  • New Features
    • Added "enhancement" as an accepted prefix for pull request titles.
  • Improvements
    • Introduced conditional execution for various jobs in GitHub Actions workflows, ensuring they run only for the GreptimeTeam/helm-charts repository.
    • Updated conditions for the release-charts-to-acr job to enhance execution control based on input parameters and events.

Copy link
Contributor

coderabbitai bot commented Dec 11, 2024

Walkthrough

The pull request introduces several changes across multiple GitHub workflow files and a configuration file. The .github/pr-title-checker-config.json file's regular expression for validating pull request titles is updated to include "enhancement" as an accepted prefix. Additionally, conditional execution is added to various jobs in the workflow files, specifically ensuring that certain jobs only run when the repository is GreptimeTeam/helm-charts. The overall structure and logic of the workflows remain unchanged aside from these conditions.

Changes

File Path Change Summary
.github/pr-title-checker-config.json Updated regular expression to include "enhancement" as an accepted prefix for pull request titles.
.github/workflows/ci.yaml Added conditional execution for the chart-test job, restricting it to run only if the repository matches GreptimeTeam/helm-charts.
.github/workflows/e2e.yaml Added conditional execution for the e2e job, restricting it to run only if the repository matches GreptimeTeam/helm-charts.
.github/workflows/release.yaml Introduced conditional execution for release and release-charts-to-acr jobs based on the repository name. Updated condition for release-charts-to-acr to include input parameter checks.

Possibly related PRs

  • refactor!: remove original config usage and add configFile and configData field #152: This PR modifies the same .github/pr-title-checker-config.json file as the main PR, specifically updating the regular expression for validating pull request titles, which is directly related to the changes made in the main PR.
  • fix: release failed #210: This PR also involves changes to the .github/workflows/release.yaml file, which may indirectly relate to the title validation process as it includes a new input parameter that could affect how releases are managed based on title prefixes.

Suggested reviewers

  • zyy17

Poem

🐰 In the garden where we play,
New titles bloom, bright as day.
"Enhancement" joins the happy crew,
With workflows dancing, fresh and new.
Hops and skips, we cheer with glee,
For changes made, oh joy, oh me! 🌼


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 082c53b and 512c3c0.

📒 Files selected for processing (1)
  • .github/workflows/release.yaml (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/release.yaml

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 generate docstrings to generate docstrings for this PR. (Experiment)
  • @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.

@daviderli614 daviderli614 requested a review from zyy17 December 11, 2024 03:09
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: 1

🧹 Outside diff range and nitpick comments (2)
.github/workflows/e2e.yaml (1)

17-17: LGTM! Consider adding documentation and improving reusability.

The repository check is a good security measure. However, consider these improvements:

  1. Add a comment explaining why this check is necessary
  2. Consider using a repository allowlist in the workflow inputs or repository variables for better reusability

Example improvement:

    runs-on: ubuntu-latest
+    # Restrict workflow to official repository to prevent unauthorized executions
-    if: ${{ github.repository == 'GreptimeTeam/helm-charts' }}
+    if: ${{ contains(fromJson(vars.ALLOWED_REPOSITORIES || '["GreptimeTeam/helm-charts"]'), github.repository) }}
.github/workflows/release.yaml (1)

Line range hint 1-94: Consider improving job dependencies and deployment verification

Two architectural improvements would make the workflow more robust:

  1. The release-charts-to-acr job should likely depend on the release job to ensure proper sequencing.
  2. Replace the hardcoded 5-minute sleep with a more reliable method to verify GitHub Pages deployment, such as polling the pages URL.

Consider this structure for job dependencies:

release-charts-to-acr:
    needs: [release]
    # ... rest of the job config

For the GitHub Pages verification, consider implementing a script that polls the pages URL with retries and timeout instead of using a fixed sleep.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between ff90aff and 082c53b.

📒 Files selected for processing (4)
  • .github/pr-title-checker-config.json (1 hunks)
  • .github/workflows/ci.yaml (1 hunks)
  • .github/workflows/e2e.yaml (1 hunks)
  • .github/workflows/release.yaml (2 hunks)
🔇 Additional comments (3)
.github/pr-title-checker-config.json (1)

7-7: LGTM! Verify team conventions for PR title prefixes.

The addition of "enhancement" as a valid PR title prefix is technically correct. However, since this affects all future PRs, please ensure this aligns with the team's conventional commit message guidelines.

Let's check if there are any documentation files that define the commit message conventions:

.github/workflows/ci.yaml (1)

8-8: Consider different conditions for push vs pull_request events.

While the repository check is good for security, it might block legitimate fork contributions. Consider:

  1. Allow PR checks from forks but with limited permissions
  2. Keep strict repository check only for push events
  3. Add documentation explaining the security rationale

Example improvement:

    runs-on: ubuntu-latest
-    if: ${{ github.repository == 'GreptimeTeam/helm-charts' }}
+    # Restrict workflow execution based on event type
+    if: |
+      ${{ 
+        (github.event_name == 'push' && github.repository == 'GreptimeTeam/helm-charts') ||
+        (github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name != github.repository)
+      }}

Let's check if there are other workflows that might need similar conditions:

✅ Verification successful

Repository check conditions are consistently implemented across workflows

Based on the verification results, all major workflows (ci.yaml, e2e.yaml, and release.yaml) consistently implement the same repository check condition if: ${{ github.repository == 'GreptimeTeam/helm-charts' }} at the job level. This shows a deliberate security pattern across the codebase.

However, let's verify the event triggers for these workflows to better assess the impact of the suggested changes:


Repository check should be adjusted for CI workflow's PR events

The verification reveals that the CI workflow is unique in accepting both push and pull_request events, while other workflows have specific triggers:

  • release.yaml: only push to main
  • e2e.yaml: manual workflow_dispatch
  • pr-title-checker.yaml: pull_request_target events

The current repository check in ci.yaml would indeed block legitimate PR contributions from forks, while other workflows either don't need changes (e2e, release) or already use appropriate events (pr-title-checker uses pull_request_target).

The original suggestion to differentiate conditions based on event type is valid and necessary specifically for the CI workflow to:

  1. Maintain strict security for push events
  2. Allow PR checks from forks
  3. Keep consistent with the repository's PR handling pattern shown in pr-title-checker.yaml
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Find all workflow files and check for repository conditions
fd -e yml -e yaml . .github/workflows/ -x sh -c 'echo "=== {} ===" && cat {} | grep -A 2 "if:"'

Length of output: 1344


Script:

#!/bin/bash
# Check workflow triggers
fd -e yml -e yaml . .github/workflows/ -x sh -c 'echo "=== {} ===" && cat {} | grep -A 3 "^on:"'

Length of output: 442

.github/workflows/release.yaml (1)

19-19: LGTM! Repository check adds proper security control.

The condition correctly restricts chart releases to the authorized repository.

Let's verify this workflow hasn't been copied to other repositories:

✅ Verification successful

Repository check is consistently implemented across workflows

The repository condition github.repository == 'GreptimeTeam/helm-charts' is properly implemented across all relevant workflow files (release.yaml, e2e.yaml, and ci.yaml), ensuring a consistent security boundary for all CI/CD operations. This is the correct approach for restricting workflow execution to the authorized repository.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if this workflow exists in other repositories
# Expected: Should only find references in GreptimeTeam/helm-charts

gh search code \
  --filename "release.yaml" \
  --path ".github/workflows" \
  --content "name: Release Charts" \
  --json repository \
  --jq '.[].repository | select(.nameWithOwner != "GreptimeTeam/helm-charts")'

Length of output: 1029


Script:

#!/bin/bash
# Let's try a different approach using ripgrep to search for similar workflow files
# and repository conditions in the current repository

# Search for workflow files with "Release Charts"
echo "=== Searching for Release Charts workflows ==="
rg -l "name: Release Charts" .github/workflows/

# Search for repository conditions in workflow files
echo -e "\n=== Searching for repository conditions in workflows ==="
rg "github.repository ==" .github/workflows/

Length of output: 726

.github/workflows/release.yaml Outdated Show resolved Hide resolved
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
@daviderli614 daviderli614 merged commit 929b54b into GreptimeTeam:main Dec 12, 2024
3 checks passed
@daviderli614 daviderli614 deleted the ci/add-checker branch December 12, 2024 02:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants