Channels
#automation-api
Title
k
kind-school-28825
11/24/2020, 4:57 AMHey all, I just wrote a short article on something that I have been working on for a bit that might come in handy for some of you who is working with github actions and pulumi. A way to create a stack on every PR, and destroy when that PR is merged to fail fast during the development cycle using the automation API. Would love to have any input 🙂 https://qasimalbaqali.medium.com/deploy-a-stack-on-every-pull-request-using-pulumi-and-github-actions-d5dbfa8946f6
❤️ 2
h
hundreds-musician-51496
11/24/2020, 11:29 PMFantastic idea, and nice write up. I'd suggest updating your implementation to use the InlineProgramArgs, for even more flexibity. When your infrastructure can be imported as a module, its very powerful. Also, TypeScript! 🙂
k
kind-school-28825
11/26/2020, 6:39 AM@hundreds-musician-51496 Thank you for the comment! I will take that into consideration, I felt like I am missing quite a lot of flexibility when it comes to writing my infrastructure, I will be tackling this issue soon.
h
hundreds-musician-51496
11/27/2020, 6:37 PMI implemented a system like this at work, and the most beneficial part was being able to make infrastructure changes part of each deploy. That is, for a given PR, I could try out new infrastructure as well as application level code changes.
👍 1
g
gifted-student-18589
12/03/2020, 6:51 PMinteresting approach regarding the destroying of stack on PR close
we have a similar situation, although we are destroying the stack immediately.. so on each event, we deploy, run Cypress against the deployed system, and then destroy
I made this action that can help you run things when the workflow is about to be done: https://github.com/webiny/action-post-run
So basically, with it, we destroy the stack, no matter if the tests have passed or failed. Without it, when the tests fail, the stack wouldn’t be destroyed. The upper action resolves this issue.
Just wanted to link that here, maybe it helps 🙂
💯 1
k
kind-school-28825
12/04/2020, 8:03 AMCool! That's actually the way I want to end up at the end. Running some tests against the deployed instances, get the results back and destroy it. I think that way it's much better, more automation. Something that maybe is pretty cool to have is to save these results somewhere, and compare them later against the newest PR and see the difference that has been made with the code changes when it comes to performance, size etc. etc.
2 Views