Is it possible to require deploys in a specific order? #303
Comments
johnseekins-pathccm
added
the
question
|
👋 Hey @johnseekins-pathccm, thanks for opening this issue! This is not the first time I have heard this request and I think its something that warrants a deep dive now. I will schedule some time to investigate if this can be done, and if so... implement it. Keep some 👀 on this issue and I'll update it as I go! It might not be right away as my schedule is pretty tight but I'll get to it when I'm able. Thank you! 🙇 |
|
@johnseekins-pathccm I was actually able to complete this faster than expected. I have published a pre-release |
|
Sorry for the bad message. This works just fine. Thanks for the quick turn-around! |
|
Actually...no. The order enforcing works too well: |
|
For some additional clarification: |
|
@johnseekins-pathccm would you be able to copy/paste your actions config for the branch-deploy step here or re-run your job with debug logs and paste those too? Feel free to redact anything that might be considered sensitive and I'll take a look to see what's up. |
|
One thing that I am noticing is that I don't see one of the little green rockets (🚀) in your screenshot. Usually if a branch successfully deploys it will say so on your pull request just below that "Deployment Results ✅" comment. I don't see that in your case so it would make sense that the deployment to Here is an example of it working for me:
|
|
Fair point, but here's that rocket: |
|
Hmm that is quite strange then.. Do you have logs or your action config that you can copy/paste here? 🙇 |
|
Here's the action config: |
|
Ah! I see. So it looks like you are completing the deployments via a custom step with Are you able to share more details about how you are setting your deployment to |
|
Here's more of the code around "finishing" a deploy. Which is essentially following the docs https://github.com/github/branch-deploy/blob/main/docs/examples.md#multiple-jobs-with-github-environments |
|
Here's (some of) the output of the staging run: And the similar prod output: I think you're right that something isn't getting set somewhere... |
|
It looks like (based again on the docs) that I'm setting state to |
I think you have found the problem! But this leads me to more questions... what is the difference between |
|
The GraphQL docs (what the action uses to fetch but not set) indicate that there is indeed an |
|
Well that's fixable. Is |
|
Alrighty, I did some investigating and I think there may be a problem in your workflow somewhere because I cannot replicate this issue in my own dev workflows. Here are some details that I have found... The The I have also done some debugging with helpful comments on this pull request: GrantBirki/actions-sandbox#115. You may find this debugging information useful and also helpful to reference the branch-deploy workflow that I am using to compare it to your to look for bugs. TL;DR: I actually think things are working as expected and I'm not able to recreate the bug that you are running into. |
|
I'm getting a very different result in API returns: |
|
|
Kinda feels like I need to say |
|
Edit: Never mind. Found the query in the code. |
|
GraphQL Query: query ($repo_owner: String!, $repo_name: String!, $environment: String!) {
repository(owner: $repo_owner, name: $repo_name) {
deployments(environments: [$environment], first: 1, orderBy: { field: CREATED_AT, direction: DESC }) {
nodes {
createdAt
environment
updatedAt
id
payload
state
ref {
name
}
creator {
login
}
commit {
oid
}
}
}
}
}Variables: {
"repo_owner": "<owner>",
"repo_name": "<repo>",
"environment": "production"
}Example results: {
"data": {
"repository": {
"deployments": {
"nodes": [
{
"createdAt": "2024-09-23T18:08:28Z",
"environment": "production",
"updatedAt": "2024-09-23T18:08:43Z",
"id": "DE_kwDOID9x8M5shzsE",
"payload": "\"{\\\"type\\\":\\\"branch-deploy\\\",\\\"sha\\\":\\\"2a000a896fb9a6b2c1bbd69608d60865be22c515\\\"}\"",
"state": "ACTIVE",
"ref": {
"name": "testing"
},
"creator": {
"login": "github-actions"
},
"commit": {
"oid": "2a000a896fb9a6b2c1bbd69608d60865be22c515"
}
}
]
}
}
}
} |
|
When you mentioned "getting a very different result in API returns" I was actually getting the same results in my experiment and it all looks as expected so that should be good 👍 |
|
I'm getting a different result: You'll notice only some of the values (and never the most recent one) come back as I had to slightly change the query to get these results: |
|
You wouldn't happen to have an If you did, there could be the possibility that it is marking your deployment as name: Deployment
on:
push:
branches:
- main
jobs:
deployment:
runs-on: ubuntu-latest
environment: production # <--- this value right here, it doesn't play well with branch-deploy
steps:
- name: deploy
# ... |
|
Perhaps the better solution would be to fetch more results and then paginate through them. As it looks like your |
|
It's absolutely the case that we were stomping on |
|
This was the problem. All along. Sorry for all the churn. These changes work great! Now to figure out deploy trains with branch deploys... |
I totally hear ya... I wish that there was more control when using the |
Details
Let's say we have two environments:
environment_targets: Staging,Production. This works fine and deploys work against both environments just fine. But what if we want to ensure that a user deploys toStagingbefore they're allowed to deploy toProduction? Essentially, is there a way to, similar to requiring reviews, require an environment be successful before another environment can be deployed to?The text was updated successfully, but these errors were encountered: