Allow users to specify the build environment when manually triggering the workflow.

[elg0nz]

• Added a new input parameter 'environment' to the workflow_dispatch event in the GitHub Actions configuration.
• The 'environment' input allows users to specify the build environment (choices: production, staging, or development) when manually triggering the workflow.
• Removed the previous method where the EXTENSION_ENV variable was set based on the current branch name.
• Updated the build step to use the user-defined 'environment' input instead of the previously utilized branch name for the EXTENSION_ENV variable.
• This change improves the flexibility and clarity of environment configuration during the CI build process.

Summary by CodeRabbit

• New Features

  • Introduced a new input parameter for the build workflow, allowing users to specify the environment (production, staging, development) for which the extension should be built.
  • Enhanced flexibility in the build process by enabling explicit user input for the build environment.

• Improvements

  • Streamlined the logic for setting the build environment variable, improving control and predictability in the build process.

[coderabbitai]

Walkthrough

Walkthrough

The changes introduce a new input parameter for the workflow_dispatch event in the GitHub Actions workflow, allowing users to specify the build environment. This input, named environment, is required and has a default value of 'development' with options for 'production', 'staging', and 'development'. The EXTENSION_ENV variable is now set based on this input rather than the branch name.

Changes

Files	Change Summary
.github/workflows/ci.yml	Added a new required input parameter environment for workflow_dispatch with default value and options. Modified logic to set EXTENSION_ENV based on the new input instead of the current branch name.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant GitHub Actions
    participant Build Process

    User->>GitHub Actions: Trigger workflow with environment input
    GitHub Actions->>Build Process: Set EXTENSION_ENV to user input
    Build Process->>GitHub Actions: Build extension
    GitHub Actions-->>User: Return build result

Loading

🐇 In the meadow, I hop with glee,
A new input for you and me!
With options to choose, oh what a delight,
Our builds now shine, oh so bright!
From dev to prod, we dance and play,
Hooray for changes, hip-hip-hooray! 🌼

---

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>.
  • 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 generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @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.

[coderabbitai]

Actionable comments posted: 0

Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

Commits

Files that changed from the base of the PR and between c947a60 and a317c4b.

Files selected for processing (1)

• .github/workflows/ci.yml (2 hunks)

Additional comments not posted (3)

.github/workflows/ci.yml (3)

5-14: LGTM!

The new input parameter environment for the workflow_dispatch event is correctly implemented. It allows users to specify the build environment when manually triggering the workflow, with a default value of 'development' and a choice of options: 'production', 'staging', and 'development'.

---

56-56: LGTM!

The EXTENSION_ENV environment variable is correctly set to the value from the newly introduced inputs.environment. This change streamlines the process of determining the build environment by allowing explicit user input.

---

62-62: LGTM!

The path for uploading the extension artifacts is correctly set to ./apps/mocksi-lite-next/dist.

[jonathankap]

Looks good

[fitzk]

I tested all of the options and it works perfectly, good job!