Added deployment trigger

[susrisha]

Added deployment trigger to deploy to Azure Static Webapps
This pull request introduces updates to the deployment workflows, mainly to improve consistency in environment naming and to automate deployments upon pull request merges. The most important changes are grouped below:

Workflow Automation:

• Added a new workflow .github/workflows/trigger-deploy-on-merge.yml that triggers the deployment process automatically when a pull request is merged into one of the main branches (develop, staging, production, or testing).

Environment Naming Consistency:

• Changed the default environment input in .github/workflows/deploy-to-azure.yml from development to develop to match branch naming conventions.
• Updated the environment mapping in the deployment workflow to use develop instead of development.

Deployment Parameter Improvements:

• Added a new parameter production_branch to the deploy-to-azure workflow, set to the selected environment.

Summary

• Added an automated Azure Static Web Apps deployment trigger for merged pull requests targeting develop, staging, production, or testing.
• Renamed the default deployment environment from development to develop and updated its mapping.
• Added production_branch configuration using the selected deployment environment.

[coderabbitai]

📝 Walkthrough

Walkthrough

The deployment workflow now uses develop as its default environment, maps it to dev, and passes the selected environment as production_branch. A new workflow dispatches deployments after merged pull requests targeting supported branches.

Changes

Azure deployment automation

Layer / File(s)	Summary
Align deployment environment inputs .github/workflows/deploy-to-azure.yml	The default environment and mapping now use develop, and the Azure deployment action receives production_branch from the selected environment.
Trigger deployment after merges .github/workflows/trigger-deploy-on-merge.yml	Merged pull requests targeting develop, staging, production, or testing trigger deploy-to-azure.yml with the pull request base branch.
Estimated code review effort: 2 (Simple)	~10 minutes

Sequence Diagram(s)

sequenceDiagram
  participant PullRequest
  participant GitHubActions
  participant DeployToAzure
  participant AzureStaticWebApps
  PullRequest->>GitHubActions: merge PR into supported branch
  GitHubActions->>DeployToAzure: dispatch workflow with base branch
  DeployToAzure->>AzureStaticWebApps: deploy with production_branch

Loading

Possibly related PRs

• TaskarCenterAtUW/workspaces-frontend#71: Modifies the same Azure deployment workflow environment mapping.

Suggested reviewers: MashB, shweta2101

Poem

I’m a rabbit hopping through the flow,
From merged PRs to Azure glow.
develop maps neatly into dev,
Branch inputs now arrive in step.
Hop, deploy, and clouds take flight!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title matches the main change by indicating a new deployment trigger, even though it is broad.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.github/workflows/deploy-to-azure.yml (1)

8-13: 🗄️ Data Integrity & Integration | 🔴 Critical | ⚡ Quick win

Fix the environment options list to include develop instead of development.

The default value develop (line 8) is not in the options list, which still contains development (line 13). Additionally, the case statement (line 27) now handles develop but no longer handles development. If someone manually dispatches this workflow and selects development from the dropdown, the case statement won't match any branch, leaving target_env unset and breaking the downstream environment output.

This also creates a cross-file contract mismatch: trigger-deploy-on-merge.yml passes environment=develop via gh workflow run, which bypasses the UI choice constraint but is inconsistent with the declared options.

🔧 Proposed fix: replace `development` with `develop` in options

             options:
                 - production
                 - staging
-                - development
+                - develop
                 - testing

Also applies to: 27-27

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/deploy-to-azure.yml around lines 8 - 13, Replace the
`development` entry in the workflow’s `environment` choice options with
`develop` so it matches the default and the value handled by the case statement.
Verify the `environment` input and `target_env` mapping consistently use
`develop` across the workflow.

Source: Linters/SAST tools

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/trigger-deploy-on-merge.yml:
- Around line 4-5: Add a job-level condition to the workflow job triggered by
the pull_request closed event, requiring github.event.pull_request.merged ==
true; apply the same guard to the corresponding deployment job block so unmerged
PR closures cannot dispatch deployments.

---

Outside diff comments:
In @.github/workflows/deploy-to-azure.yml:
- Around line 8-13: Replace the `development` entry in the workflow’s
`environment` choice options with `develop` so it matches the default and the
value handled by the case statement. Verify the `environment` input and
`target_env` mapping consistently use `develop` across the workflow.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: cb76b404-4cb6-4960-9a0b-104a55e5889f

📥 Commits

Reviewing files that changed from the base of the PR and between 0184cb1 and e71b513.

📒 Files selected for processing (2)

• .github/workflows/deploy-to-azure.yml
• .github/workflows/trigger-deploy-on-merge.yml

[coderabbitai]

🩺 Stability & Availability | 🔴 Critical | ⚡ Quick win

Guard the job to only run when the pull request was actually merged.

types: [closed] fires for both merged and unmerged PRs. Without an if condition, closing a PR without merging would dispatch a deployment, potentially deploying rejected code. Add a job-level merged check.

🔒 Proposed fix: add merged check to the job

 jobs:
     deploy-frontend:
+        if: github.event.pull_request.merged == true
         runs-on: ubuntu-latest

Also applies to: 11-12

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/trigger-deploy-on-merge.yml around lines 4 - 5, Add a
job-level condition to the workflow job triggered by the pull_request closed
event, requiring github.event.pull_request.merged == true; apply the same guard
to the corresponding deployment job block so unmerged PR closures cannot
dispatch deployments.