1. A way to see the "description" on a deployment status. We use this to provide details about why the deployment was transitioned to that state.

Ha, this is actually a personal gripe I've had for many years as well. 😖

I'll chat with our designers about this gap, I have at least one idea for how to work it in. That said, if you have any suggestions on how you would like to see the description values, we would take them into consideration. 👂🏻

2. It seems that the branch/tag of a deployment is only shown when you specify the "refs/" prefix. If I create a deployment at heads/master it does not show the branch, but if I do refs/heads/master then it does (see picture). Maybe there's an explanation for this, but it seems weird to me when both resolve to the same branch.

I chatted with our git systems experts on this one, but the general consensus is that heads/master is not a standard format for referring to a branch. While some git operations can manage to resolve heads/master to refs/heads/master, other git operations expect it to resolve to refs/heads/heads/master (:warning: note the duplicated heads/ segment).

Our recommendation is that you stick to one of the two standard branch name formats of either just the branch name (e.g. master) or the full reference path (e.g. refs/heads/master).

3. A way to create deployments from the UI.

What would you envision for this feature? Since basically every repository has some custom mechanism for their deployments (GitHub Pages, GitHub Actions, third party deployers like Vercel, etc.), creating a deployment is a slightly unclear task. I have one non-trivial idea here, but would love to hear any ideas you might have to offer without being biased by mine. 🤔

4. The deployment says "Deployed to by ". It would be great if "" was clickable and would take you to the deployments for that environment, similar to clicking on an environment in the sidebar on the left.

Great idea! The current implementation leaves us with an unfortunate edge case that prevented me from just going ahead and adding this now, so I've added a task for our backlog to get back to this in the near future. 🔜

First of all, thank you very much for reviewing and responding to my post!

1. A way to see the "description" on a deployment status. We use this to provide details about why the deployment was transitioned to that state.

Ha, this is actually a personal gripe I've had for many years as well. 😖

I'll chat with our designers about this gap, I have at least one idea for how to work it in. That said, if you have any suggestions on how you would like to see the description values, we would take them into consideration. 👂🏻

The main thing I'm interested in is the description on the latest status, so if that would show up as its own column in the list of deployments that would work great for us. It would also be nice to be able to perhaps click on and expand a deployment and that could show a scrollable view of all its deployment statuses (and their respective descriptions 😄).

2. It seems that the branch/tag of a deployment is only shown when you specify the "refs/" prefix. If I create a deployment at heads/master it does not show the branch, but if I do refs/heads/master then it does (see picture). Maybe there's an explanation for this, but it seems weird to me when both resolve to the same branch.

I chatted with our git systems experts on this one, but the general consensus is that heads/master is not a standard format for referring to a branch. While some git operations can manage to resolve heads/master to refs/heads/master, other git operations expect it to resolve to refs/heads/heads/master (⚠️ note the duplicated heads/ segment).

Our recommendation is that you stick to one of the two standard branch name formats of either just the branch name (e.g. master) or the full reference path (e.g. refs/heads/master).

I see. The main argument I have for why it should be the way that I suggested is that the deployment feature itself resolves refs in either format (refs/heads/master or heads/master) and exposes it in the sha field. It's not a critical thing for us, I just didn't expect that behavior and was confused about why sometimes deployments would display a branch and sometimes not.

3. A way to create deployments from the UI.

What would you envision for this feature? Since basically every repository has some custom mechanism for their deployments (GitHub Pages, GitHub Actions, third party deployers like Vercel, etc.), creating a deployment is a slightly unclear task. I have one non-trivial idea here, but would love to hear any ideas you might have to offer without being biased by mine. 🤔

I want a way that replicates the API request. A button in the top-right corner of the deployments page called "Create deployment" and it would open a modal and have me fill out fields like environment, ref, payload, etc. Once I've filled out the fields I'd click "Deploy" and off it goes.

I don't know if our deployment model is unusual or non-obvious, so I'll quickly explain it.

We use manual deployments (as in, a person uses our CLI tool which calls POST /repos/.../deployments which would be Deployed to nicolai0/sandbox by @nicolai0) as a way to trigger some environment to track a particular ref. Subsequent pushes to that ref would then create an automated deployment (which would be Deployed to nicolai0/sandbox by my-custom-bot).

So for example, let's say I have a sandbox environment. I have made a PR for some code I want to test on that environment before merging it to master. So what I do is I create a GitHub deployment with the heads/my-branch ref. Then we have a GitHub App which takes that webhook and starts the deployment on the nicolai0/sandbox environment. Whenever I push a commit to my branch, my-custom-bot will create a deployment and deploy that new commit. Once I'm done testing, I'd create a new deployment manually and move the ref back to heads/master. Any push to master will now trigger an automated deployment on sandbox again.

Having a button in the GUI would free us from having every developer who need to do a deployment having to install our custom CLI tool. It could also be a button in the PR itself, then it could automatically determine the ref.

4. The deployment says "Deployed to by ". It would be great if "" was clickable and would take you to the deployments for that environment, similar to clicking on an environment in the sidebar on the left.

Great idea! The current implementation leaves us with an unfortunate edge case that prevented me from just going ahead and adding this now, so I've added a task for our backlog to get back to this in the near future. 🔜

Good to hear!