Rename generate_publish_release and all doc references

Author: Genevieve Nuebel

…b/workflows/generate_publish_release.yml …/workflows/openapi-generate-and-push.yml.github/workflows/generate_publish_release.yml renamed to .github/workflows/openapi-generate-and-push.yml .github/workflows/generate_publish_release.yml renamed to .github/workflows/openapi-generate-and-push.yml

@@ -1,4 +1,4 @@
-name: Generate Publish Release
+name: "OpenAPI: Automated Generate and Push"
 
 on:
   repository_dispatch:

docs/ARCHIVED/SDK-Generation-Publishing-Flow.md

@@ -31,11 +31,11 @@ Both flows use the same underlying generation logic but differ in how they handl
 ## Flow 1: Automatic Generation (Repository Dispatch)
 
 ### Trigger
-OpenAPI specifications in the upstream `openapi` repository change → Repository sends `repository_dispatch` event to `mx-platform-node` → `generate_publish_release.yml` workflow is triggered
+OpenAPI specifications in the upstream `openapi` repository change → Repository sends `repository_dispatch` event to `mx-platform-node` → `openapi-generate-and-push.yml` workflow is triggered
 
 ### Current Implementation
 
-**Workflow**: `.github/workflows/generate_publish_release.yml`
+**Workflow**: `.github/workflows/openapi-generate-and-push.yml`
 
 This is the **production flow** that automatically generates, publishes, and releases SDKs when upstream APIs change.
 
@@ -233,7 +233,7 @@ supportsES6: true
 
 **Used by**: 
 - `generate.yml` (manual generation)
-- `generate_publish_release.yml` (automatic generation)
+- `openapi-generate-and-push.yml` (automatic generation)
 - `version.rb` script
 
 ### openapi/templates/
@@ -356,9 +356,9 @@ sequenceDiagram
 | `NPM_AUTH_TOKEN` | publish.yml | Authenticate to npm registry for publishing |
 | `GITHUB_TOKEN` | All workflows | GitHub API access (auto-provided, but sometimes explicitly referenced) |
 | `SLACK_WEBHOOK_URL` | All workflows | Send failure notifications to Slack |
-| `PAPI_SDK_APP_ID` | generate_publish_release.yml | GitHub App ID for custom token generation |
-| `PAPI_SDK_INSTALLATION_ID` | generate_publish_release.yml | GitHub App installation ID |
-| `PAPI_SDK_PRIVATE_KEY` | generate_publish_release.yml | GitHub App private key |
+| `PAPI_SDK_APP_ID` | openapi-generate-and-push.yml | GitHub App ID for custom token generation |
+| `PAPI_SDK_INSTALLATION_ID` | openapi-generate-and-push.yml | GitHub App installation ID |
+| `PAPI_SDK_PRIVATE_KEY` | openapi-generate-and-push.yml | GitHub App private key |
 
 ### Environment Setup
 

docs/Adding-a-New-API-Version.md

@@ -108,9 +108,9 @@ The `ConfigValidator` automatically validates that:
 
 **No workflow changes needed** — the existing validation step in `generate.yml` calls `ConfigValidator` with your new version, and it automatically validates using the updated mapping.
 
-### 2.2 Update generate_publish_release.yml
+### 2.2 Update openapi-generate-and-push.yml
 
-This workflow is automatically triggered by the OpenAPI repository to generate and publish SDKs for all versions in parallel.
+This workflow is automatically triggered by the OpenAPI repository to generate and push SDKs for all versions in parallel.
 
 **Location 1: Version-to-config mapping**
 
@@ -198,7 +198,7 @@ Check that your YAML is valid for all three modified files:
 
 ```bash
 ruby -e "require 'yaml'; puts YAML.load(File.read('.github/workflows/generate.yml'))"
-ruby -e "require 'yaml'; puts YAML.load(File.read('.github/workflows/generate_publish_release.yml'))"
+ruby -e "require 'yaml'; puts YAML.load(File.read('.github/workflows/openapi-generate-and-push.yml'))"
 ruby -e "require 'yaml'; puts YAML.load(File.read('.github/workflows/on-push-master.yml'))"
 ```
 
@@ -364,7 +364,7 @@ Use this checklist to verify you've completed all steps:
 - [ ] Major version in config is unique and sequential (4.0.0 for v20300101)
 - [ ] Updated `.github/workflows/generate.yml` with new version in dropdown options
 - [ ] Updated `.github/config_validator.rb` with new version in `SUPPORTED_VERSIONS` mapping
-- [ ] Updated `.github/workflows/generate_publish_release.yml` with version-to-config mapping in Setup job
+- [ ] Updated `.github/workflows/openapi-generate-and-push.yml` with version-to-config mapping in Setup job
 - [ ] Updated `.github/changelog_manager.rb` with new version in `API_VERSION_ORDER` array
 - [ ] Updated `.github/workflows/on-push-master.yml` path triggers with `v20300101/**`
 - [ ] Updated `.github/workflows/on-push-master.yml` publish job matrix with new version
@@ -404,9 +404,9 @@ Use this checklist to verify you've completed all steps:
 **Cause**: Wrong major version in config file  
 **Solution**: Update `npmVersion: 4.0.0` in config file to use unique major version
 
-### generate_publish_release.yml doesn't recognize new version
+### openapi-generate-and-push.yml doesn't recognize new version
 **Cause**: Version-to-config mapping missing in Setup job, ChangelogManager not updated, or ConfigValidator not updated  
-**Solution**: Verify three locations are updated: (1) version-to-config mapping in generate_publish_release.yml Setup job, (2) add version to `API_VERSION_ORDER` in `changelog_manager.rb`, and (3) add version to `SUPPORTED_VERSIONS` in `config_validator.rb`
+**Solution**: Verify three locations are updated: (1) version-to-config mapping in openapi-generate-and-push.yml Setup job, (2) add version to `API_VERSION_ORDER` in `changelog_manager.rb`, and (3) add version to `SUPPORTED_VERSIONS` in `config_validator.rb`
 
 ### on-push-master.yml doesn't trigger after merge
 **Cause**: Path trigger syntax incorrect or matrix not updated  
@@ -426,7 +426,7 @@ Once verified:
 2. **Create PR**: Get code review of workflow changes
 3. **Merge PR**: Once approved, merge to master
 4. **Wait for OpenAPI updates**: New version won't generate until OpenAPI repo sends it in payload
-5. **Monitor first generation**: Watch the automatic `generate_publish_release.yml` run when OpenAPI repo triggers it
+5. **Monitor first generation**: Watch the automatic `openapi-generate-and-push.yml` run when OpenAPI repo triggers it
 
 ---
 

docs/Multi-Version-SDK-Flow.md

@@ -28,7 +28,7 @@ Each version is independently generated, tested, published to npm, and released
 ## Three Ways Things Happen
 
 ### 🤖 Flow 1: Automatic (Upstream Triggers)
-OpenAPI spec changes → `generate_publish_release.yml` runs → SDK generated, published, released
+OpenAPI spec changes → `openapi-generate-and-push.yml` runs → SDK generated, published, released
 
 **When**: OpenAPI repository sends `repository_dispatch` with API versions  
 **Who**: Automated, no human intervention  
@@ -173,15 +173,15 @@ sequenceDiagram
 
 | File | Purpose | Used By |
 |------|---------|---------|
-| `.github/workflows/generate_publish_release.yml` | Automatic generation from upstream API changes | OpenAPI repo |
+| `.github/workflows/openapi-generate-and-push.yml` | Automatic generation from upstream API changes | OpenAPI repo |
 | `.github/workflows/generate.yml` | Manual generation with version selection | Developer |
 | `.github/workflows/on-push-master.yml` | Auto-publish trigger with path-based matrix | Any master push |
 | `.github/workflows/publish.yml` | Publishes SDK to npm | publish_release & on-push-master |
 | `.github/workflows/release.yml` | Creates GitHub release | publish_release & on-push-master |
 | `.github/version.rb` | Bumps version in config files | Workflows |
 | `.github/clean.rb` | Removes old generated files | Workflows |
-| `openapi/config-v20111101.yml` | Config for v20111101 generation | generate_publish_release & generate |
-| `openapi/config-v20250224.yml` | Config for v20250224 generation | generate_publish_release & generate |
+| `openapi/config-v20111101.yml` | Config for v20111101 generation | openapi-generate-and-push & generate |
+| `openapi/config-v20250224.yml` | Config for v20250224 generation | openapi-generate-and-push & generate |
 | `openapi/templates/package.mustache` | npm package.json template | OpenAPI Generator |
 | `openapi/templates/README.mustache` | README.md template | OpenAPI Generator |
 

docs/Troubleshooting-Guide.md

@@ -33,7 +33,7 @@ Check in this order:
 
 ### Generate Workflow: Configuration Validation Fails
 
-The `generate.yml` and `generate_publish_release.yml` workflows run configuration validation before SDK generation. If validation fails, the workflow stops immediately to prevent invalid configurations from generating code.
+The `generate.yml` and `openapi-generate-and-push.yml` workflows run configuration validation before SDK generation. If validation fails, the workflow stops immediately to prevent invalid configurations from generating code.
 
 **Validator**: `.github/config_validator.rb`
 
@@ -275,7 +275,7 @@ fatal: A release with this tag already exists
 - Workflow runs at 2:02 PM but CDN still has 2:00 PM version
 - SDK generated from stale spec
 
-**Solution**: Already implemented in `generate_publish_release.yml`
+**Solution**: Already implemented in `openapi-generate-and-push.yml`
 - Uses commit SHA in spec URL: `raw.githubusercontent.com/mxenabled/openapi/<commit-sha>/openapi/v20111101.yml`
 - Commit SHA bypasses CDN and guarantees exact spec version
 - Nothing to do—this is automatic

docs/Workflow-and-Configuration-Reference.md

@@ -10,7 +10,7 @@
 ## Flow 1: Automatic Multi-Version Generation (Repository Dispatch)
 
 ### Trigger
-OpenAPI specifications change in the upstream `openapi` repository → Repository sends `repository_dispatch` event with optional `api_versions` payload → `generate_publish_release.yml` workflow is triggered
+OpenAPI specifications change in the upstream `openapi` repository → Repository sends `repository_dispatch` event with optional `api_versions` payload → `openapi-generate-and-push.yml` workflow is triggered
 
 ### Backward Compatibility Model
 - **No Payload (v20111101 only)**: If openapi repo sends `repository_dispatch` without `api_versions` field, defaults to generating v20111101 only
@@ -21,7 +21,7 @@ This allows phased migration: current behavior works as-is, and when the openapi
 
 ### Implementation
 
-**Workflow**: `.github/workflows/generate_publish_release.yml`
+**Workflow**: `.github/workflows/openapi-generate-and-push.yml`
 
 #### Step 1: Setup - Determine Versions to Generate
 
@@ -130,7 +130,7 @@ strategy:
 **Architecture**: After `Commit-and-Push` completes and pushes to master, the automatic `on-push-master.yml` workflow is triggered by GitHub's push event.
 
 **Why This Architecture?**
-- Separates concerns: `generate_publish_release.yml` owns generation, `on-push-master.yml` owns publishing
+- Separates concerns: `openapi-generate-and-push.yml` owns generation, `on-push-master.yml` owns publishing
 - Enables consistent publish logic: All publishes (whether from automated generation or manual PR merge) go through the same workflow
 - Prevents duplicate publishes: Manual generate.yml + PR merge only triggers publish once (via on-push-master.yml)
 
@@ -431,7 +431,7 @@ The `npmVersion` field in the config file is the **authoritative source of truth
 
 **When It's Called**:
 - `generate.yml`: After generating a single API version (manual flow)
-- `generate_publish_release.yml`: After generating multiple API versions (automatic flow)
+- `openapi-generate-and-push.yml`: After generating multiple API versions (automatic flow)
 
 **Example Output**:
 ```markdown
@@ -604,7 +604,7 @@ OpenAPI Repo: Commits change to v20111101.yml and v20250224.yml
         ↓
 repository_dispatch: {"api_versions": "v20111101,v20250224"}
         ↓
-generate_publish_release.yml: Triggered
+openapi-generate-and-push.yml: Triggered
         ├─ Setup: Create matrix from api_versions
         ├─ Matrix[v20111101]: Clean, Bump, Generate (parallel)
         ├─ Matrix[v20250224]: Clean, Bump, Generate (parallel)