New deployments no longer setting previous deployments to inactive.

[patrickvinograd]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

Since last week's Github Actions outage, we've noticed inconsistent behavior with regard to deployments. Previous deployments are no longer getting marked as inactive in most of our environments when a new deployment is created. We're relying on the GHA behavior wherein a deployment is created when the workflow/job sets an environment: parameter. And per documentation:

When you set the state of a deployment to success, then all prior non-transient, non-production environment deployments in the same repository with the same environment name will become inactive.

This is very similar to https://github.com/orgs/community/discussions/67982. We've confirmed none of the caveats/conditions listed in that issue apply to us - we haven't changed anything in our workflow definitions in the last while.

Curiously, there are one or two environments where it seemed like old deployments were getting marked as inactive. One difference was that these environments included some failed deployments in their history. I can't confirm that's 100% the difference maker though.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[tomm1990]

the auto-inactive behavior is narrower than people expect, and the outage timing might be a red herring.

from the docs you quoted: github only flips older deployments to inactive when the new one reaches success, and only for non-transient, non-production environments with the same name. production environments keep history active on purpose.

so i’d check these first, per environment:

1. is the environment marked production in Settings → Environments? if yes, auto-inactive will not run. that also explains “most envs broken, one or two still work.”
2. look at the deployment object, not just the job conclusion. job can be green while the deployment stays pending / never gets success - then nothing gets inactivated.

   gh api repos/OWNER/REPO/deployments --jq '.[:5] | .[] | {id, environment, production_environment, transient_environment, created_at}'
   gh api repos/OWNER/REPO/deployments/DEPLOYMENT_ID/statuses --jq '.[0] | {state, created_at}'

3. reusable workflows / environment: on a called job can create a deployment against a different ref or a slightly different env name (Staging vs staging is fine; staging vs staging-app is not).

workaround until github fixes whatever broke after the outage:

# mark an old deployment inactive
gh api -X POST repos/OWNER/REPO/deployments/OLD_ID/statuses \
  -f state=inactive

or after each successful deploy, list prior success deployments for that environment and set them inactive yourself.

if those envs are already non-production and the new deployment status is actually success, then yeah - that’s the #67982 - class bug and support is the next step.

[AndresPinerosZen]

I don't see any "production" setting under "Settings -> Environments" when navigating the project's GUI, but I can see the production_environment setting in the Deployments. Seems like the production_environment is a setting associated with the deployment and not the environment?

[tomm1990]

yeah, that’s basically the catch.

there isn’t a big “production: true/false” toggle on the environment settings page. the thing that actually decides this behavior is the deployment object github creates, and that’s why production_environment shows up there.

so for this bug i wouldn’t trust the GUI alone. i’d check the actual deployment records:

gh api repos/OWNER/REPO/deployments --jq '.[:10] | .[] | {id, environment, production_environment, transient_environment, created_at}'
gh api repos/OWNER/REPO/deployments/DEPLOYMENT_ID/statuses --jq '.[] | {state, created_at}' 

if the deployments that refuse to inactivate old ones are coming through with production_environment: true, then github is doing what it normally does for production and keeping history active.

if they’re production_environment: false, transient_environment: false, same environment name, and the new deployment status really reaches success, then i’d treat it as the platform bug path again, not config.

so yeah - environment config matters indirectly, but the source of truth for this specific behavior is the deployment payload, not the Settings page.