Running Deploy-PolicyPlan.ps1 both locally and in Github action fails on new setup

[ThomasStubergh]

Running the Build-DeploymentPlans.ps1 script works fine and generates a plans-$env:pacEnvironment folder containg a policy-plan.json. This works both locally and in Github action. Unfortunately when I try to run the Deploy-PolicyPlan.ps1 it fails with the below error message.

The Output and Input folder is the same when running both scripts, but there seems to be some logics creating an environment plan folder in the Output folder which again contains the policy-plan.json file. Not sure if the DeployPolicyPlan.ps1 has taken this into account, and the script seems to fail in this part:

It could of course be something I have set up or configured incorrectly, and if so I would need some pointers to what I could have done wrong.

FYI I have managed to set up a working Github Action Build Deployment Plan Workflow, which creates a PR, but fails after approving and the deployment workflow is running.

[anwather]

Are you deploying the plan using the command below: specifically adding the pacEnvironment parameter?

Deploy-PolicyPlan -definitionsRootFolder $env:definitionsRootFolder -inputFolder $env:planFolder -pacEnvironment $env:pacEnvironment

There is an example workflow in the StarterKit which you can copy - it should work...

[ThomasStubergh]

Are you deploying the plan using the command below: specifically adding the pacEnvironment parameter?

Deploy-PolicyPlan -definitionsRootFolder $env:definitionsRootFolder -inputFolder $env:planFolder -pacEnvironment $env:pacEnvironment

There is an example workflow in the StarterKit which you can copy - it should work...

Thank for the quick reply. I figured out my problem this morning. I guess there is just some thing I didn't understand with the deployment process when using the github action workflow. And I still don't completely understand this workflow and the intention. I guess this workflow is a simplified workflow only meant to run a plan against 1 environment and then deploy against the same environment. This is where it went wrong for me. I thought the intention was to test against dev/test management group and then deploy against prod. When I read the documentation I understood it as a test deployment against dev/test management group, then a prod deployment against prod, and I see that is probably what is solved with the azure devops single tenant workflow. We might not actually need this complexity as of now, but for the arguments sake. How could we solve this in github action workflow? I have now managed to deploy to the dev/test management group, but if I was to now deploy the same policies and policy set to a prod management group in the same tenant, if I duplicated the same workflows, pointed them to prod and then ran it, would it understand that the policies and policy sets should be moved to prod?

My next question would be what happens when you then add more policies and definitions for testing and run the test build, wouldn't it then move everything back the t\dev/test management group? Or is there something keeping track of what's been deployed to test, and then to prod so it isn't moved back?

I realize that this is maybe outside the scope of your support, and we probably can live just fine with deploy directly to prod.

Some feedback:

• Have you looked into OIDC authentication against github? I needed to modify the workflow in order to leverage OIDC instead. Let me know if you want that setup as well and maybe i can contribute?
• Also, not sure if there has been som changes on the type of permissions you have in a github repo, or if it's because we are on a free version, but i needed to grant specific permission for the jobs in order to have enough permission for the github_token to create pull requests and clean up etc. I ended up with giving write-all under jobs on both the build and deploy workflow. It didn't work giving permission in the github GUI for the repo to have read/write and to create PR.
• I think also the .gitignore created some issues, as it then does not create the Output folder when creating it locally and pushing to remote repo. I ended up removing the remove item from .gitignore in the workflow as well. Maybe I need it for something, but I couldn't figure out for what. To me it seemed like it actually made the build workflow omit the plan file from the pull request, so only the body.txt was sent.

[anwather]

Yes I've looked into OIDC - just haven't had a chance to implement. I am missing the instructions for setting up the GitHub permissions. It is only designed for a simple workflow - the background is that we have done a lot in Azure DevOps around the pipeline so this was the first foray into GitHub actions. I need to have a good think about what this would look like in dev/test workflow - just haven't had time.

[ThomasStubergh]

Ok. Thanks for your feedback. You can close this issue, and I will change the workflow to deploy against prod instead. Great work with this solution though. Looking forward to testing it more!