You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This repository uses GitHub Actions with webhook-based deployment. The deployment workflow automatically triggers when code is pushed to specific branches.
-**`WEBHOOK_SECRET`:** The secret token that matches `DEPLOY_WEBHOOK_SECRET` in your staging server's `.env` file
116
+
-**Note:** Use `http://` until SSL certificate is configured, then update to `https://`
117
+
118
+
3.**Configure Production Environment:**
119
+
- Click on `production` environment (or create it if it doesn't exist)
120
+
- Add the following secrets:
121
+
-**`WEBHOOK_URL`:** Your production webhook endpoint URL
122
+
-**`WEBHOOK_SECRET`:** The secret token that matches `DEPLOY_WEBHOOK_SECRET` in your production server's `.env` file
123
+
124
+
**Important Notes:**
125
+
- Each environment (staging/production) has its own set of secrets
126
+
- The `WEBHOOK_SECRET` must match the `DEPLOY_WEBHOOK_SECRET` value in the corresponding server's `.env` file
127
+
- Environment secrets are only accessible to workflows that explicitly reference that environment
128
+
- The workflow file (`.github/workflows/deploy.yml`) uses `environment: ${{ github.ref == 'refs/heads/main' && 'production' || 'staging' }}` to automatically select the correct environment based on the branch
129
+
130
+
#### How It Works
131
+
132
+
1. Developer pushes code to `dev` or `main` branch
133
+
2. GitHub Actions workflow triggers
134
+
3. Workflow determines environment based on branch (`dev` → `staging`, `main` → `production`)
135
+
4. Workflow retrieves environment-specific secrets (`WEBHOOK_URL` and `WEBHOOK_SECRET`)
136
+
5. Workflow sends POST request to the webhook endpoint with authentication
137
+
6. Server receives webhook, validates secret, and runs deployment script
138
+
7. Deployment script pulls latest code, builds, and restarts the application
139
+
78
140
## Reverse Proxy (Nginx)
79
141
80
142
The application is served through nginx as a reverse proxy. Configuration files are located at:
@@ -117,100 +179,48 @@ sudo systemctl status nginx
117
179
118
180
### DNS Record Setup
119
181
120
-
To set up a staging subdomain (e.g., `staging.processordb.mit.edu`), you'll need to request a DNS record from MIT IT.
182
+
**Status:** The DNS record for `staging.processordb.mit.edu` has been set up by MIT IT and is currently active.
121
183
122
-
**Information needed for DNS request:**
123
-
-**Subdomain:**`staging.processordb.mit.edu` (or your preferred subdomain)
124
-
-**Record Type:**`A` record (for IPv4)
125
-
-**IP Address:**
126
-
-**Same server as production:**`128.52.132.49` (current server IP)
127
-
-**Different server:** The public IP address of the staging server instance
128
-
129
-
**Current production server IP:**`128.52.132.49`
130
-
131
-
**How to request:**
132
-
1. Contact MIT IT/IS&T DNS administrators
133
-
2. Request an A record pointing `staging.processordb.mit.edu` to the appropriate IP address
134
-
3. Wait for DNS propagation (typically 5 minutes to 48 hours, usually within 15-30 minutes)
184
+
**Current Configuration:**
185
+
-**Domain:**`staging.processordb.mit.edu`
186
+
-**Record Type:**`A` record
187
+
-**IP Address:**`128.52.141.130` (staging server IP)
188
+
-**Status:** Active and resolving
135
189
136
190
**Verify DNS is working:**
137
191
```bash
138
192
# Check if DNS record exists
139
193
dig +short staging.processordb.mit.edu
140
194
141
-
# Should return the IP address you requested
195
+
# Should return: 128.52.141.130
142
196
```
143
197
144
-
### Recommended Order of Operations
198
+
### Current Staging Setup
145
199
146
-
**Configure nginx BEFORE requesting DNS**- This ensures everything is ready when DNS propagates:
200
+
**DNS Status:**Configured by MIT IT - `staging.processordb.mit.edu` points to `128.52.141.130`
147
201
148
-
1.**First: Set up nginx configuration** (including internal-only restrictions if needed)
149
-
2.**Second: Set up SSL certificate** (can use staging cert or wait for DNS)
150
-
3.**Third: Request DNS record** from IT services
151
-
4.**Fourth: Verify everything works** once DNS propagates
202
+
The staging environment is currently configured with:
152
203
153
-
**Why configure first?**
154
-
- When DNS propagates, the site will work immediately
155
-
- You can test nginx config using the IP address before DNS is ready
156
-
- Avoids confusion if DNS is ready but site doesn't work
0 commit comments