Replies: 1 comment
-
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Question
Body
Hi all
This question might be mroe relvant to the
Azure/static-web-apps-deploy
action, but here goes anyway. The discussion might inspire a better solution.I've been playing around with creating a workflow for deploying to Azure static web app using the PR preview feature.
Out of the box this works greatg with the workflow file created by Azure.
As I'm primarily managing resources and environments in GitHub i set out to create a solution that would reflect the preview environemtns in the Azure static web app in GitHub.
I'll post my workflow file here and discuss what issues i am encountering below.
It's a somewhat small addition to the auto-generated workflow file form Azure.
There's a couple of small issues here that bothers me, namely:
environment
property on job (https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment). Again a workaround exists where you can manually create the environment alongside the deployment via the api in the workflow - this does however have the unpleasent side effect of forcing me to push deployment status updates manually where as the environment prop on the job hadnles that part neatly.So in essence some of this might be an improvement suggestion.
Why isn't it possible to assign permissions for deleting environments within workflows? i get that some might fear malicious actions that will attempt to delete envrionments. But couldn't this be handled rather easy by requiring specific permisison properties on the given job/workflow?
Does anyone know what transient_environment prop on deployment creation actually do? I have a hard time finding an explanation for what's it's technical use is within GitHub.
Has anyone found another interesting way to track Azure staic web app previews within GitHub?
Beta Was this translation helpful? Give feedback.
All reactions