[Feedback Tracking] 🚀 GA - New Deployments dashboard view is now generally available!

[JamesMGreene]

Select Topic Area

Product Feedback

Body

📣 On April 25, 2024, we shipped the new dashboard view UI experience for Deployments to general availability! 🚀

Along this ship, the Deployments dashboard now includes the following enhancements:

• 🔻 Filtering! You can now drill down into the list of deployments based on multiple factors.
  • Available filter dimensions including environment, creator, ref, and state/status.
  • All of these filter dimensions support inclusive OR behavior.
• 📌 Environment Pinning! You can now pin up to 10 of your most critical environments to provide a quick way to view all of their latest deployments.
  • ℹ️ Caveat: This is only currently available to repositories that are not owned by a user or organization on a free plan. This isn't an intentional premium feature, but rather than unexpected miscalculation of permissions from technical debt. We are aware of the issue, and hope to resolve it in the future, but it unfortunately may not be fixed immediately due to shifting priorities.

Quick links:

• Documentation
• Changelog post

Please leave your feedback as a comment! 💬

---

Previous Beta Announcement 📣

📣 On August 3, 2023, we shipped a new dashboard view UI experience for Deployments. This is a stepping stone on our roadmap toward a renewed focus on Continuous Delivery. 🚀

For now, users may choose to opt-out of the new experience using GitHub's feature preview settings. If you do opt-out, we would love to hear why. 👂🏻

You can learn more about this change in our changelog post.

Quick links:

• Documentation
• Demo video
• Changelog post

[Harshsanas]

loved

[Harshsanas]

ok

[HenrikDK]

The overview already shows if its main branch, but it would be very helpfull if it could also show the release name if theres a release tag associated with the deployment.

[joshft91]

Hi @JamesMGreene - apologies for bugging you, but wondering if I can get your thoughts on my comment above here regarding deploying from tags/releases. Is the only way to do that via a workflow event that would use on: push: tags: ...?

[N-Usha]

@joshft91 - Triggering workflows is currently supported based on Tags and Releases too.. Is there anything more specific that you are looking for?

[joshft91]

Hey @N-Usha - thanks for responding. I was wondering if there was a way to trigger a deployment from a tag when the workflow itself is triggered from a branch push.

I have a workflow that triggers from on: push: branches: release/v*. If I then make a branch (e.g. release/v1.2.3) and push, our workflow then creates a tag from that branch name (e.g. v1.2.3). When @JamesMGreene mentioned that creating a deployment from tag/release would preserve the tag name in the deployments page, that got me wondering if it was possible to do a deployment from a tag that hadn't yet been created. See my comment here about how the branch name disappears after deleting the release branch

[nnordrum]

What would be extremely helpful is if this was available across the org, like the security stuff, and filterable by repo topics and by environments (e.g. "show me all repos that have one of the topics [back_end, integration_layer] and show the following environments if they exist [stage, production]"

This way you could easily build views that show you what's deployed across your org. Ideally, the environments would be columns. e.g.

repo	development	test	stage	production
App-A	1.1.4	1.1.3	1.1.2	1.1.1
App-B	1.1.4	1.1.3	1.1.2	1.1.1
App-C	1.1.4	1.1.3	1.1.2	1.1.1
App-D	1.1.4	1.1.3	1.1.2	1.1.1
App-E	1.1.4	1.1.3	1.1.2	1.1.1
App-F	1.1.4	1.1.3	1.1.2	1.1.1
App-G	1.1.4	1.1.3	1.1.2	1.1.1

or put a badge there? would make it more reusable...

[JamesMGreene]

Elevating environments into an organization-wide view is an idea that is still floating around our internal discussions.

While I don't think it will be necessary or even desirable for every organization, I think it will be of interest to quite a few who try to keep very standardized environments across repositories as you've hinted at here. Pivoting based on repository topics is also an interesting idea.

Thank you for the feedback! 🙇🏻

[nnordrum]

I don't think you need to make Environments Org-wide; just group by Environment presence based on name.

Org-wide would just force them to be the same, but I would bet (at least within the scope of a repo topic for shared orgs) that Environment names are overwhelmingly consistent (within the scope of a repo topic for shared orgs).

While we're asking for the stars, the ability to order the Environments in the query would be nice too 😃

[nnordrum]

also, I want to point out that the filtering by topic is vital, because otherwise you'd get Production for a different app/group/etc.

[KritsanaWaingin]

Thank

[mauritz-lovgren]

In a typical micro-service architecture with tens (or even hundreds) of repos using the same target deployment environments, it would be very beneficial to have an organisational overview of all repo deployments.

[JamesMGreene]

Cross-reference to help track this separate feedback discussion:

• https://github.com/orgs/community/discussions/62650

[taiidani]

Some feedback from my team's testing of the new UI:

• We have a lot of transient, inactive deployments -- on the scale of 500. These deployments are showing up in the sidebar and pushing down active environments extremely far. Could deployment environments with Active deployments be hoisted to the top of the sidebar so they aren't buried by all the Inactive deployments?
• The picture in the feature preview toggle (below) showing Active deployments as cards in the UI doesn't appear for us. We get the list of deployments, but no cards for our ~6 Active deployments. Are we seeing a bug, or is this planned/unplanned future work?

[taiidani]

@dylanatsmith Ah, that would explain why none of our active deployments are getting cards. We use prod for production and a boutique name for staging.

All of our transient deployments are coming from preview environments that we deploy from our PRs, so users are able to surface the Status/URL of the deployment from the Pull Request UI. It's not necessary for them to appear prominently in the Deployments UI, but having them in the "Latest deployments" list has been nice for visibility.

That said, pinning on the sidebar for our persistent environments to surface them from the ocean of transient deployments would be very helpful! I don't think our personal use case would motivate us to pin anything except those with "Active" deployments though, and we likely won't make the effort to manually pin transient environments unless we can pin a regex/prefix pattern. If there were an "Active Environments" filter on the sidebar we probably wouldn't elect to pin at all!

[dylanatsmith]

This is very useful, thank you!

[KritsanaWaingin]

Thank

[pcarney8]

🙏 please include the associated ref in that "active environments" summary too 🙏

[heyitscoco]

+1000! A search bar to filter for the specific one would also be great.

[dylanatsmith]

Hi @Filipdominik, this discussion is specifically about the deployments dashboard on GitHub. For help deploying your site, you’ll need to ask elsewhere.

[Filipdominik]

Thanks!

[sbrudz-orum]

I'm liking the new deployments UI. Very happy that we can now see the tag that was deployed.

Some feedback/questions:

• Could you display the deployment description if it exists? We put the name of the person who triggered the deployment there (via the GitHub REST API called by a bot user). It would be very helpful to see it. (or better yet have a way to set the name of the deployer via the REST API call)
• In the new UI, github-pages gets pulled to a special "Active deployments" section but none of our other environments show up there. Instead they're buried in the chronological list of deployments. How can we indicate the environments that should show up in the "Active deployments" section?
• We noticed that on the new UI, we can only see the "View Logs" link for active deployments. It would be nice to be able to View Logs for the inactive deployments, too.
• For older, inactive GitHub Pages deployments, we're seeing them all link to the same PR, which is confusing. We changed the default branch of the repository in June, so maybe that's causing an issue with the history.
  

[gouldre]

I also hoped to be able to "View Logs" of inactive deployments. This was missing from the old screen, and was the main reason I was excited to see this release, but alas, it is still missing.
This is useful to me as a DevOps/Release Engineer because I occasionally need to deploy an old release as a way to roll back, and it is very difficult and error prone to find the last deployment that ran up to the "prod" environment. The only way I can do this currently is to go to the CI / CD workflow in the project, and click on every single run starting from the top until I find the last time it got to that env, and hope I didn't miss one. The "deployments" UI is exactly the solution I need... but the link is missing! and only on the previously successful, "inactive" deployments! so frustrating.

Edit: We trigger on the "push" event, so the PR link is also not applicable for us.

[JamesMGreene]

Thank you for your feedback! ❤️

• Could you display the deployment description if it exists?

I'd like to see these as well -- and the corresponding per-status description values even more so. Will need to chat through how to work these into the UI with our designers, but I have a task in our backlog to do so in the future.

(or better yet have a way to set the name of the deployer via the REST API call)

You might be able to achieve this if you use a GitHub App to generate user-specific tokens instead of using a single faux-bot user PAT. 🤔 🤷🏻

• In the new UI, github-pages gets pulled to a special "Active deployments" section but none of our other environments show up there. Instead they're buried in the chronological list of deployments. How can we indicate the environments that should show up in the "Active deployments" section?

For this beta, we specifically seek out only environments named either github-pages or production. We knew this was likely to be a frustrating limitation in the short term, though they are statistically the most common environment names by a huge margin. We do plan to revisit this elevation approach in the future, considering alternative options such a frequency (more like the old UI), environment pinning, etc.

We are also planning to implement more advanced filtering options, which should provide another avenue for getting to your desired environment.

• We noticed that on the new UI, we can only see the "View Logs" link for active deployments. It would be nice to be able to View Logs for the inactive deployments, too.

This was also the case in the old UI. As noted elsewhere in this discussion, this is actually a data problem rather than a UI problem, but the most common situation where this happens is likely being caused by GitHub's internal auto-inactivating behavior. I've added a task to our backlog to investigate if we can improve that, since I agree that maintaining that logs_url would be useful for many folks. 👍🏻

• For older, inactive GitHub Pages deployments, we're seeing them all link to the same PR, which is confusing. We changed the default branch of the repository in June, so maybe that's causing an issue with the history.

That's a curious one. 🤔 Any chance this is in a public repository? If so, I would love to take a closer look at the data involved there.

[sbrudz-orum]

• Could you display the deployment description if it exists?

I'd like to see these as well -- and the corresponding per-status description values even more so. Will need to chat through how to work these into the UI with our designers, but I have a task in our backlog to do so in the future.

Great! Thank you!

(or better yet have a way to set the name of the deployer via the REST API call)

You might be able to achieve this if you use a GitHub App to generate user-specific tokens instead of using a single faux-bot user PAT. 🤔 🤷🏻

I'll look into that. Thanks!

• In the new UI, github-pages gets pulled to a special "Active deployments" section but none of our other environments show up there. Instead they're buried in the chronological list of deployments. How can we indicate the environments that should show up in the "Active deployments" section?

For this beta, we specifically seek out only environments named either github-pages or production. We knew this was likely to be a frustrating limitation in the short term, though they are statistically the most common environment names by a huge margin. We do plan to revisit this elevation approach in the future, considering alternative options such a frequency (more like the old UI), environment pinning, etc.

That makes sense. We use prod instead of production, so we're not seeing it. It's annoying but we can live with it for a while. FWIW, I like @airtonix's idea of specifying the important environments in a config file in the .github directory of the repo.

• We noticed that on the new UI, we can only see the "View Logs" link for active deployments. It would be nice to be able to View Logs for the inactive deployments, too.

This was also the case in the old UI. As noted elsewhere in this discussion, this is actually a data problem rather than a UI problem, but the most common situation where this happens is likely being caused by GitHub's internal auto-inactivating behavior. I've added a task to our backlog to investigate if we can improve that, since I agree that maintaining that logs_url would be useful for many folks. 👍🏻

Sounds good. Thank you!

• For older, inactive GitHub Pages deployments, we're seeing them all link to the same PR, which is confusing. We changed the default branch of the repository in June, so maybe that's causing an issue with the history.

That's a curious one. 🤔 Any chance this is in a public repository? If so, I would love to take a closer look at the data involved there.

It is a private repository. I'm seeing the same behavior on another of our private repos, too. Both repos have master as the default branch and all PRs are squash merged in. The GitHub Pages setting are:

[KritsanaWaingin]

Thank

[JamesMGreene]

We have shipped an improvement to maintain the logs link for a deployment after it is auto-inactivated by GitHub. 🚀

 

ℹ️ Note that similar behavior was not added at the REST/GraphQL API level, though. Users manually sending in their state: "inactive" deployment status updates must provide the log_url parameter themselves.

[alekseyrozh]

I can't see the environments anymore? I'm quite confused where envs have gone as right now I only a see a flat list of deployments from all envs

[alekseyrozh]

@JamesMGreene that's right, now I see a few hundred environements there 😀 Any advise on how to remove all the envs (these are inactive and were not shown before the gh updated the UI)?

[alekseyrozh]

@JamesMGreene I just looked through the APIs trying to figure out how to delete these 500+ environments with no deployemnts that I have, and it got me super confused.

• /repos/OWNER/REPO/environments returns me a 404 for that repo. I believe this is not the deployment environments, but some other environments endpoint
• /repos/OWNER/REPO/deployments?environment=preview-PR-100 returns me an empty array of deployments, which makes sense cause there's no deployments there, however there's a deployment environment there and I don't see a way to delete it.

Overall it's quite confusing that there are 2 concepts of environements (as I understand it) and there doesn't seem to be any endpoints or UI to manage/create/delete deployment environments. For now i'm left with 500+ inactive envs with 0 deployments in each and I don't see a way out of this. Please let me know what i'm missing

[JamesMGreene]

I'm afraid to say that you aren't missing anything right now. 😭

The TL;DR: is that what was preventing you from seeing your Environments to begin with is some permissions confusions due to some awkward growing pains of this very old feature (Deployments) being adapted into more modern features like Actions. I have created an issue in our backlog to do a more complete audit of our Environment-related permissions checks. The current sad state is roughly limited to private repositories whose repo owner (user/org) are on a free-tier plan, but we do plan to improve it. ☹️

[alekseyrozh]

@JamesMGreene understood. So how would I create a deployment for a transient environment, so that I can delete it later (both deployment and so that the environment doesn't show up in that list)?

[JamesMGreene]

If you're allowing Actions to the create the Deployments on your behalf (using the Job-level environment: syntax), then, unfortunately, there isn't a way to configure the deployments as transient today. 💔

Customizing the Actions-based deployments is something we're hoping to look into it in the future. In the meanwhile, as mentioned above, I've also proposed editing the permissions to allow free users/orgs to at least maintain their Environments, even if they can't used the more advanced features. 🤞🏻

Apologies for not having better news to deliver. 😓

[m0un10]

Thank you so much for this feature! It couldn't have come at a better time.
Just as I was dreading having to explain to release engineers, how to find a set of release candidates by filtering branches in the workflow view, this feature popped up, and now I can just direct them to the deployment view. It is awesome! Now, they can just click on the environments to see if there is anything available to deploy.

My only two items of feedback:

• if an item is waiting to be deployed (yellow clock icon), there is no way to trigger the deployment from the list item. The way to do it is click "View logs" and then it will show the waiting deployment. That was a bit unintuitive. I only realised I could do that after first clicking the main link (which just went to the commit view).
• when an environment is in a waiting to deploy state it shows in the list as "Deployed to". Should it instead say something like "Ready to deploy to..."? This is a minor bit of feedback because the yellow clock icon at least makes it clear visually.

[JamesMGreene]

Regarding to your original feedback items, I have added items for each to our backlog. Thank you! 💝

[m0un10]

Thank you! If we could filter on workflow, or at the very least see the workflow name in the deployments list, it would significantly improve our ease of use. We are currently going to have to workaround it by building a bot that makes the release candidates per workflow clearer. It's a bit to convoluted for the release engineers to jump into the workflows and filter on the release branch. Building it a bot feels a little bit overkill for something that might not be hugely difficult to address in the product itself. Thanks again.

[ric-whitehead-bbc]

I second this. Having it display the workflow would be useful.

[ypolonsky]

Please, please, add the workflow name to deployments list, do not assume that you have only one workflow deployment per environment! I'm sure many users will support this.

And even if this is not related to deployments view - I need a way to see input parameters values for a deployment - currently, I have to add a workflow step to print out the list of input parameters into log - this is not the way CI/CD should work

[sam-mathews]

if an item is waiting to be deployed (yellow clock icon), there is no way to trigger the deployment from the list item. The way to do it is click "View logs" and then it will show the waiting deployment. That was a bit unintuitive. I only realised I could do that after first clicking the main link (which just went to the commit view).

Personally this is the most frustrating part of the UI for people in our org. Even after doing many deployments there is still a cognitive load to remember where to go. It definitely feels like you have to jump through too many hoops to find the modal that lets you trigger the deployment modal. Ideally it would be accessible 1-2 clicks away from the main repository screen.

At the moment it feels like I'm going off the beaten track each time I want to deploy. Aside from that, everything is working great though. Thanks!

[rocklan]

Love it, but PLEASE get rid of the "Show more environments" link that shows if you have more than 10 environments. Just show them all or give it a higher limit or remember to show them all or something. (Same problem with the existing "Show more workflows..." link, it drives me insane)!!

[dylanatsmith]

Hi @rocklan, in both cases the limitation is there to prevent performance issues from populating long lists on page load, though we’re aware of challenges with finding the environments and workflows you’re looking for in both lists.

How many environments (and how many workflows) do you commonly have for repositories where you experience this friction?

[thor]

It's a nice, iterative improvement over the previous iteration. My primary feedback would be to support monorepos in a more official capacity. At the moment, with our internal deployment tool that uses GitHub Deployments under the hood, we split environments into two components: a project and an environment name. E.g my-cat-server/production. The exact character used to split isn't important.

That said, official support for multiple "projects" in a repository would be helpful both to avoid such fragile features on top of this, as well as allowing the environments list on the left to filter by projects.

[austinpray-mixpanel]

The UI in general doesn't seem built with monorepos in mind. No way to filter environment names either.

[JamesMGreene]

Very valid feedback regarding the difficulty of using this new UI with monorepos. 😓

We'll be sure to iterate on this when we implement more advanced filtering capabilities in the future.

[jeremyckahn]

I am no longer able to run deployments with this new UI. I had to revert to the old version in order to promote a commit from a lower environment to a higher one. Please fix this before removing the old version!

[JamesMGreene]

@jeremyckahn Can you please expand on what process/steps you are using to promote that commit? I'm not familiar with any built-in workflow for that on GitHub, but would love to hear more about it. Please let us know! 🙇🏻

[jeremyckahn]

Hi @JamesMGreene, I can't share screenshots or a video because it is a private repo. In any case, I usually promote commits through environments like so:

1. Scroll to "Deployments" on the repo.
2. Click the environment I want to promote to.
3. Click the "Deployed" link under the commit I want to promote. This takes me to the pending deployment view.
4. Click "Review pending deployments."
5. In the modal that appears, click the checkbox to give permission and then click the "Approve and deploy" button.

In the new UI, the "Deployed" link in step 3 is not present, so I cannot proceed.

[JamesMGreene]

Ahhh, got it! Just a difference in the terminology I'm used to. Thanks for bringing that to our attention, we'll take a look at fitting something into the current design. 👍🏻

As a workaround for now, you should be able to find the same link as View logs in the kebab menu on the right:

[jeremyckahn]

Oh yeah, that works! Thanks for pointing that out, @JamesMGreene. Ideally the new workflow would not introduce an additional click, but a clearer indication that the approval UI is gated behind the kebab menu would also suffice.

[davidsr2r]

I opted out personally. We have many many deploys and it was too hard to see which was the latest deploy to each server. That's all I wanted. Additionally, the list of deployments isn't a complete list -> is that because deployments that are down / expired aren't listed? If so, it would be nice to be able to see that. It would also be nice to be able to sort the currently active deployments by server name & by deployment time.

[dylanatsmith]

Hi @davidsr2r, sorry to hear this ship is missing the mark for you.

How many servers do you have with active deployments at any time?

[JamesMGreene]

We would definitely expect all deployments for the repository to be present (on some page) when you have selected the All environments view.

Please correct me if I'm wrong, but I'm assuming you may be referring to there be missing "Environments" from the left sidebar's list of environments, which is more likely. 😓 That sidebar list is populated based on the Environments that currently exist for your repository. However, for some deployment workflows, environments are deleted afterward, causing a bit of a gap between the current environments and "all of the environments that have ever been deployed to" for a repository.

We have some tasks in our backlog to implement more advanced filtering options, including status, and one of which I hope to be allowing a user to filter by any of the "all of the environments that have ever been deployed to" rather than just the current environments. 🤞🏻

Thank you for your feedback!

[barclayadam]

We use many parallel steps (as reusable workflows) to deploy multiple applications to multiple regions. All of these workflows declare the use of a single environment (production or uat), because we require the secrets from them.

The dashboard counting each one as a completely independent dashboard is useless information and means seeing actual atomic deployment is impossible. I've run the overall workflow 15 times, but this dashboard tells me we have performed 533 deployments:

[shaedrich]

Maybe, there should be something like "sub environments" (something along the lines of UAT.US, UAT.EU, PROD.US, PROD.EU, etc.), which could be handled in some kind of grouped fashion … 🤔

[juanitosvq]

#62676 (comment)

[barclayadam]

For our use case "sub environments" would still not quite do.

We have multiple applications that run in parallel against the same environment (regional or not), but they are still logically part of a single deployment.

I'd like to see some ability to record deployments against a complete workflow as one atomic unit, then each job can specify the "portion" of that deployment it contributes to. A tree structure of sorts

[MisterJimson]

Deployments are unusable until actions/runner#2120 is fixed

[enghitalo]

It would be cool if you could disable third-party deploys like this within github itself

[nfx]

we use environments to execute integration tests. i wonder if we can rename Deployments to something more sensible?

[MisterJimson]

actions/runner#2120

[jonnyhoeven]

Love most of it, Would love it if GitHub pages settings could be defined from repository, for example. For a custom domain you can add a CNAME file to the root of the repository, but the rest of the settings are found outside the code base: https://github.com/jonnyhoeven/justme.dev/settings/pages This makes it hard to understand the CNAME file for people new to the repository. Would be nice if the deployment to github was part of .github/workflows maybe just a "mock" workflow that override the web based configuration and include the contents of the CNAME file.

[ConnorDarghaoui]

I like it, but can I use it for GitHub Pages? Or does it have any errors?

[JamesMGreene]

GitHub Pages deployments will show up in the new Deployments dashboard. 👍🏻

ℹ️ One exception to that would be GitHub Enterprise Server usage where Pages runs on its own legacy build infrastructure [for now] instead of using Actions.

[DanRigby]

Should visiting the Deployments dashboard be changing the selected repository tab from Actions to Code?

This appears intentional (the link on the Actions tab has the arrow icon), but it feels a bit out of place under the Code tab.

[JamesMGreene]

Totally valid question.

We've discussed it several times, but not all deployments are Actions-based. Combine that with the fact that some repositories do not have Actions enabled, and you find yourself in a scenario where it would need to be associated with Actions in some repos but Code in others. We opted to keep it simple by just leaving deployments associated with the Code tab, as they always have been historically. 🤷🏻

[br3ndonland]

"Active" label is confusing

There was a screenshot posted previously that showed a checkmark icon to indicate active/inactive and a label to indicate "Latest" (https://github.com/orgs/community/discussions/62676#discussioncomment-7463513).

I'm now seeing the "Latest" label has been changed to "Active". This is confusing because a deployment could look like it's both active and inactive at the same time.

For example, in a repo that uses environments when publishing Python packages to PyPI with OIDC, the deployments widget says the environment is "inactive".

If I click on the environment to go to the deployments dashboard, I can see the latest deployment has a grayed-out checkmark but is also labeled "Active".

This is doubly confusing. Why would a deployment with a grayed-out checkmark be labeled "Active"? And why would the latest deployment have a grayed out checkmark?

Why was the "Latest" label changed to "Active"? Should the "Active" label maybe say "Latest" instead?

[robertLichtnow]

Under the deployments of a specific environments, I'd like to enrich the data of the card below.
It's hard to understand what's actually deployed there if I'm doing anything that's custom and not tied to a specific commit.
Being able to add either a description text or any kind of metadata would be great.

[jamesliu4c]

This is superb!

On the selected deployments at the top, is there a way to configure what is selected? I'd like 2, I'm sure others would like a few more than that.

[redbeard]

Two pieces of feedback:

1. Possible bug: Dashboard still shows deployment environments as main, even though they were changed to deploy from a different branch ('production')
2. Request for clarification: Dashboard shows deploys for postgres service, which in itself is not deployed from code and doesn't have 'deploys' associated with it in Render, where is this coming from?

[JamesMGreene]

📣 On April 25, 2024, we shipped the new dashboard view UI experience for Deployments to general availability! 🚀

Along this ship, the Deployments dashboard now includes the following enhancements:

• 🔻 Filtering! You can now drill down into the list of deployments based on multiple factors.
  • Available filter dimensions including environment, creator, ref, and state/status.
  • All of these filter dimensions support inclusive OR behavior.
• 📌 Environment Pinning! You can now pin up to 10 of your most critical environments to provide a quick way to view all of their latest deployments.
  • ℹ️ Caveat: This is only currently available to repositories that are not owned by a user or organization on a free plan. This isn't an intentional premium feature, but rather than unexpected miscalculation of permissions from technical debt. We are aware of the issue, and hope to resolve it in the future, but it unfortunately may not be fixed immediately due to shifting priorities.

Quick links:

• Documentation
• Changelog post

Please leave your feedback as a comment! 💬

[navignaw]

Thanks for sharing! This is a super cool view to see our deployments.

One feature we would love to have is the ability to filter by run-name. In our GitHub Action, we customize deploys to various services in our monorepo using:

run-name: "Deployment- Environment: ${{ inputs.environment }}, Service: ${{ inputs.service-name }}"

However, there doesn't seem to be any way to view this in the dashboard, nor any way to filter or search on it. This makes it difficult to see at a glance which service a deployment was made for. Thanks!

[zburgermeiszter]

Better monorepo support would be awesome.
In monorepos, multiple applications are deployed from the same repo to a given environment.

[austinpray-mixpanel]

+1 on better monorepo support. We use github deployments on a tiny majority of the services we deploy in our monorepo and it's already way out of hand. Ability to control the ordering of pins would be nice!

If I had to be prescriptive: there needs to be first class support for segmenting deploys by deployment phase or by other labels. Examples:

• Our webapp is first deployed to staging then to production
• Our stateful storage systems deploy to canary -> zone-1 -> zone-2
  How do we manage this without blowing up the number of deployment targets in a multiplicative way?

[NickIannelli]

Having the deployment filters as part of a URL query string param would be ideal, so that it can be linked, bookmarked etc.

[KhushalGupta]

In the review deployment page, if I Cancel Workflow, shouldn't it automatically reject the deployment ? Rather currently, it waits for the Approvers to Reject it and then it is cancelled ?

[taku333]

This function is wonderful.
This is the kind of functionality I was hoping for!
 
As for feedback,It would be helpful to have the commit number on the screen, although I can see it if I drill down.
The default branch is often not enough to make a decision.