How can I update subscription details in a PR while its branch is in a read-only merge queue?

Below is one recommended approach—and its tradeoffs—that many have adopted when trying to “squeeze” a dual‑repo, cross‑step process into a single PR. In short, you’ll need to introduce an automated “update” commit after final deployment even if that means temporarily leaving the merge queue, then programmatically re‑adding the branch. One example is an enhanced version of Option 4 (pushing to a different branch then auto‑merging) but using a bot or automation to “update in place.” Here’s how:

Summary of the Approach

1. Initial PR with Placeholders
   Create the PR in Repo 1 with the placeholder subscriptionId and the corresponding file (with its placeholder file name) in Repo 2. This step kicks off the process.

2. Deploy and Capture the Real Subscription ID
   The deployment app provisions the subscription. When the real subscriptionId is known, it also computes the new file name for Repo 2 (using, for example, Python’s sub_id.split("-")[-1]).

3. Automated Update Commit via a Bot
   Use a bot (or an automated process with proper privileges) that:

   • Checks out the feature branch used for the PR.
   • Updates the subscription.yaml in Repo 1 with the real subscriptionId.
   • Renames or creates the file correctly in Repo 2 (now using the correct file name).
   • Creates the Entra ID group with the matching name.

   Key point: Although pushing to a merge-queue branch can remove it from the queue, your bot must use GitHub’s API with an admin token or bypass method so that you can update the branch and then re‑enqueue it automatically.

4. Re‑Enqueue the PR
   After the update commit, call the GitHub API (or use your internal tools if available) to re‑add the branch into the merge queue. This “seamless” update ensures that everything happens within what is conceptually one PR even though behind the scenes you have an extra commit.

Practical Considerations

• Merge Queue Limitations: Because the merge queue branch is “read-only,” you have to work around that by updating the underlying branch on which the merge queue artifact was built. This means you need elevated permissions or a bot account with rights to bypass branch protections.
• Transient Removal from the Queue: Even if the update commit temporarily removes the PR from the merge queue, your automation must then explicitly re‑enqueue it. GitHub’s API supports this workflow if you have a bot or admin token.
• Atomicity vs. Process Complexity: Although the end goal is a single logical PR, the implementation ends up having two distinct phases. Migration of state between them must be carefully managed to avoid inconsistencies.
• Alternative Options:
  • Maintaining external state (like a database) may work but introduces external dependencies and potential consistency issues.
  • Pushing from the deployment app directly might re‑trigger deployments, which is why you’re trying to avoid it.
  Thus community experience suggests that augmenting Option 4 with a bot-assisted update commit (and re‑adding the branch to the merge queue) is the most robust integrated solution.

Example Pseudocode for the Update Bot

Below is a pseudocode example of what your bot might do after your deployment step completes:

PYTHONCopied
import requests

# Configuration variables
GITHUB_API = "https://api.github.com"
REPO_OWNER = "your_org_or_user"
REPO_NAME = "Repo1"  # similarly for Repo2 in your bot process
BRANCH = "feature/subscription-update"
BOT_TOKEN = "your_github_bot_token"

headers = {
    "Authorization": f"Bearer {BOT_TOKEN}",
    "Accept": "application/vnd.github+json"
}

def update_subscription_yaml(new_subscription_id):
    # Logic to checkout branch, update subscription.yaml
    # For example, use Git commands or the GitHub content API
    update_commit_data = {
        "message": "Update subscription.yaml with real subscriptionId",
        "committer": {"name": "Subscription Bot", "email": "bot@yourcompany.com"},
        "content": "base64-encoded-updated-content",  # update the file content
        "sha": "previous_file_sha"
    }
    url = f"{GITHUB_API}/repos/{REPO_OWNER}/{REPO_NAME}/contents/subscription.yaml"
    response = requests.put(url, json=update_commit_data, headers=headers)
    response.raise_for_status()

def update_repo2_file(new_file_name):
    # Create or update the file in Repo2 with the desired file name.
    # This could be a new file creation call to GitHub's API.
    pass

def reenqueue_pr(pr_number):
    # Use the GitHub API or your internal API to requeue the PR.
    url = f"{GITHUB_API}/repos/{REPO_OWNER}/{REPO_NAME}/pulls/{pr_number}/merge-queue"
    # This is a placeholder; actual endpoints may differ.
    response = requests.post(url, headers=headers)
    response.raise_for_status()

# Pseudocode execution:
if __name__ == '__main__':
    final_subscription_id = "subscription_guid_real"
    new_file_suffix = final_subscription_id.split('-')[-1]
    new_repo2_file = f"azure-sub-{new_file_suffix}.yaml"
    
    update_subscription_yaml(final_subscription_id)
    update_repo2_file(new_repo2_file)
    
    # Optionally, update or create the Entra ID group here through an external API call.
    
    pr_number = 123  # Extract the PR number dynamically if needed
    reenqueue_pr(pr_number)

Note: The real implementation would depend on your environment and GitHub’s specific API endpoints. The key takeaway is that the bot performs the update commit and then re‑queues the PR.

Conclusion

Because you cannot push changes directly to a merge-queue branch without side effects, the only practical solution involves an automated update (even if it means temporarily stepping out of the merge queue) and then programmatically re‑adding it. While it may seem “messy,” this bot‑assisted commit is currently the only way to achieve your goal of a single logical PR that spans both your subscription provisioning and file updates in two repositories.