Document the current GHA build and deploy workflows

[derekadombek]

Description

This PR is specific to the build and deploy workflows explaining requirements, reasoning and what we had in mind for the possible future.

Screenshots (if applicable)

Related Issues

[Link any related issues or tasks from your project management system.]

Checklist

• The title of this PR is descriptive and concise.
• My changes follow the style guidelines of this project.
• I have added or updated test cases to cover my changes.
• I've let the team know about this PR by linking it in the review channel

[marycrawford]

Hey Derek, I know you are OOO this week so I did a quick cursory review of your PR. Will go over it again after I work on priority work this week. Feel free to add other folks on the team for review of the documentation as well. There is no rush! Enjoy your conference and will have this review completed when you return on Monday.

[marycrawford]

Looking good. Some comments.

[marycrawford]

I am a bit confused, I thought you mentioned to Bora and Pri that we were only going to work with one environment (dev) since you stated the demo environment was unstable. Are we still doing two environments now? If so, this is something we will have to discuss with the other engineers since they are still under the impression that we will have these two environments.

[marycrawford]

Thanks for meeting with me yesterday (11/18) and explaining that the demo environment is considered unstable which meant that it was simply another non-production environment. In addition, that we were only using it to demo to prospective partners. I believe your explanation resolves this comment.

[marycrawford]

I would remove the uncertainty of At the time of reading this, may need since anyone using this to You will need.

[marycrawford]

Perhaps say To build versus If you would like to build.

[marycrawford]

The requirements should have some bullet point items of what individuals need to build or run things locally or to gain access to the repository.

For example:

• Admin privileges to Github Settings
• Azure admin privileges to your account
• Terraform installed

Recommend updating the wording of the current Prerequisites to something more definitive:

You will need to update the secrets and following variable values: AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID.

Not sure if the Resource Group name have to be changed. Azure documentation states the Resource Group name must be unique within a subscription and between 1 and 90 characters long. Perhaps note if there is an error when they run terraform regarding the resource group, they can change it to a unique name between 1-90 characters.

[derekadombek]

💯 agree with

The requirements should have some bullet point items of what individuals need to build or run things locally or to gain access to the repository.

For example:

Admin privileges to Github Settings
Azure admin privileges to your account
Terraform installed
Recommend updating the wording of the current Prerequisites to something more definitive:

You will need to update the secrets and following variable values: AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID.`

for this part:

`Not sure if the Resource Group name have to be changed. Azure documentation states the Resource Group name must be unique within a subscription and between 1 and 90 characters long. Perhaps note if there is an error when they run terraform regarding the resource group, they can change it to a unique name between 1-90 characters.

Thank you!

The reason they are required to use that naming convention, is to match how they're being variablized in Github Actions. The caveat to that however, is who ever take this over in the future are able to change that but they will need to change it in both places(Azure and Github Actions) I could explain that but I think thats a little out of scope for this document, because if someone wants to change that they most likely will have good knowledge of how Github Action deployments work with Azure.