Bug: GitHub repo 404 Not Found

[autocloudarc]

When executing the following command:

Deploy-Accelerator -iac "terraform" -Cicd "alz_github" -inputs "C:\onedrive-prsn\OneDrive\02.00.00.GENERAL\repos\alz-tfa\accelerator\config\ghb-inputs.yaml" -output .\output -Verbose

...I receive these error messages, which appear to indicate that the two repositories could not be created and therefor could not be found.

Plan: 69 to add, 2 to change, 6 to destroy.
╷
│ Error: GET https://api.github.com/repos/auto-cloud-arc/alz-mgmt: 404 Not Found []
│
│   with module.github.github_actions_environment_variable.azure_plan_client_id["plan"],
│   on ..\..\modules\github\action_variables.tf line 1, in resource "github_actions_environment_variable" "azure_plan_client_id":
│    1: resource "github_actions_environment_variable" "azure_plan_client_id" {
│
╵
╷
│ Error: GET https://api.github.com/repos/auto-cloud-arc/alz-mgmt: 404 Not Found []
│
│   with module.github.github_actions_environment_variable.azure_plan_client_id["apply"],
│   on ..\..\modules\github\action_variables.tf line 1, in resource "github_actions_environment_variable" "azure_plan_client_id":
│    1: resource "github_actions_environment_variable" "azure_plan_client_id" {
│
╵
╷
│ Error: GET https://api.github.com/repos/auto-cloud-arc/alz-mgmt/actions/oidc/customization/sub: 404 Not Found []
│
│   with module.github.github_actions_repository_oidc_subject_claim_customization_template.alz,
│   on ..\..\modules\github\oidc_templates.tf line 1, in resource "github_actions_repository_oidc_subject_claim_customization_template" "alz":
│    1: resource "github_actions_repository_oidc_subject_claim_customization_template" "alz" {
│
╵

Time taken to complete Terraform plan:

Days Hours Minutes Seconds Milliseconds
---- ----- ------- ------- ------------
0    0     0       29      626

Expected Behavior

These errors should not have appeared and would instead prompt me to continue with the terraform 'apply' phase.

Current Behavior

See error provided above.

Possible Solution

Steps to Reproduce

1. After installing the ALZ module and editing the input file ghb-inputs.yaml wit the values below

# Basic inputs
# The Infrastructure as Code (IaC) tool to use for the deployment. (e.g. 'terraform'). NOTE: Only 'terraform' is relevant here.
iac: "terraform"
# The bootstrap module to use for version control system to use for the deployment. (e.g. 'alz_github')
bootstrap: "alz_github"
# The starter module to use for the deployment. (e.g. 'complete')
starter: "complete"

# Bootstrap inputs
# The personal access token for GitHub: alz-tfm-pat-01
github_personal_system_access_token: <redacted>
github_organization_name: "<redacted>arc"

# Controls whether to use a separate repository to store pipeline templates. This is an extra layer of security to ensure that the azure
# credentials can only be leveraged for the specified workload
use_separate_repository_for_templates: "true"
# Azure Subscription ID for the bootstrap resources (e.g. storage account, identities, etc). Leave empty to use the az login subscription
# (A valid subscription id GUID e.g. '12345678-1234-1234-1234-123456789012')
bootstrap_subscription_id: "<redacted>23c"
# Used to build up the default resource names (e.g. rg-<service_name>-mgmt-uksouth-001) (A valid Azure name with no hyphens and limited
# length e.g. 'abcd')
service_name: "alz"
# Used to build up the default resource names (e.g. rg-alz-<environment_name>-uksouth-001) (A valid Azure name with no hyphens and limited
# length e.g. 'abcd')
environment_name: "mgmt"
# Used to build up the default resource names (e.g. rg-alz-mgmt-uksouth-<postfix_number>) (A number e.g. '1234')
postfix_number: "1"
# Controls whether to use self-hosted agents for the pipelines
use_self_hosted_agents: "true"
# Personal access token for GitHub Runners to register themselves: alz-tfm-pat-02
github_runners_personal_access_token: <redacted>                              
# Controls whether to use private networking for the agent to storage account communication
use_private_networking: "true"
# Allow access to the storage account from the current IP address. We recommend this is kept off for security
allow_storage_access_from_my_ip: "true"
# Apply stage approvers to the action / pipeline, must be a list of SPNs separate by a comma (e.g. abcdef@microsoft.com,ghijklm@microsoft.com) using team "alz-mgmt-approvers"
apply_approvers: "<redacted>@outlook.com"
# Create branch policies for the main branch
create_branch_policies: "true"

# Shared interface inputs
# Azure Deployment location for the bootstrap resources (e.g. storage account, identities, etc)
# (An Azure deployment location e.g. 'uksouth')
bootstrap_location: "eastus2"
starter_location: "eastus2"
# The root parent management group display name. This will default to 'Tenant Root Group' if not supplied
root_parent_management_group_display_name: "Tenant Root Group"
# This is the id of the management group that the ALZ hierarchy will be nested under, will default to the Tenant Root Group
# (A valid Azure name e.g. 'my-azure-name')
root_parent_management_group_id: "<redacted>8f9"
# The identifier of the Identity Subscription. (e.g '00000000-0000-0000-0000-000000000000')
# (A valid subscription id GUID e.g. '12345678-1234-1234-1234-123456789012')
subscription_id_identity: "<redacted>310"
# The identifier of the Management Subscription. (e.g 00000000-0000-0000-0000-000000000000)
# (A valid subscription id GUID e.g. '12345678-1234-1234-1234-123456789012')
subscription_id_management: "<redacted>c5f"
# The identifier of the Connectivity Subscription. (e.g '00000000-0000-0000-0000-000000000000')
# (A valid subscription id GUID e.g. '12345678-1234-1234-1234-123456789012')
subscription_id_connectivity: "<redacted>8dc"

# Starter Module Specific Variables
# The location for Azure resources. (e.g 'uksouth')
# (An Azure deployment location e.g. 'uksouth')
default_location: "eastus2"
# The default postfix for Azure resources. (e.g 'landing-zone') #
# (A valid Azure name e.g. 'my-azure-name')
default_postfix: "landing-zone"
# The path of the configuration file
# (A valid yaml or json configuration file path e.g. ''c:\\my-folder\\my-config-file.yaml`)
configuration_file_path: ""

3. Update the ...config.yaml with the desireed root_name:, root_id: and email_security_contact: values.
4. Execute the following PowerShell script

Deploy-Accelerator -iac "terraform" -Cicd "alz_github" -inputs "C:\onedrive-prsn\OneDrive\02.00.00.GENERAL\repos\alz-tfa\accelerator\config\ghb-inputs.yaml" -output .\output -Verbose

Context (Environment)

I am not able to perform the bootstrap phase of the deployment to create the necessary GitHub org repository and environment configuration, which is a blocker to complete the deployment of the landing zones in Azure.

• Operating System and version as reported by $PSVersionTable.OS:
• PowerShell versions as reported by $PSVersionTable.PSEdition:

Name                           Value
----                           -----
PSVersion                      7.4.5
PSEdition                      Core
GitCommitId                    7.4.5
OS                             Microsoft Windows 10.0.22631
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

I am unable to demonstrate the Terraform Azure Landing Zones accelerator deployment to guide and prepare customers for their own landing zone deployment.

Detailed Description

See screenshot below:

[autocloudarc]

Note, the ALZ version I'm using is 3.0.3 that was updated yesterday (28aug2024). The workaround as of right now was simply to create that first repository manually (alz-mgmt) in my GitHub organization to kick start the process but will leave this opened still for an opportunity to identity and resolve the root cause.

[autocloudarc]

Update: I discovered that if we install the GitHub cli (gh), we can also simple do the following to more easily fix directly from the command line or IDE terminal:

gh auth login
$org = "<your-github-organization-name>"
gh repo delete $org/alz-mgmt --yes

[jaredfholgate]

Hi @autocloudarc. I'm not sure I am understanding the workaround here. Are you saying this is an intermittent issue with the GitHub API? How does deleting the repo with gh help here?

[autocloudarc]

Hi @jaredfholgate . Thanks for following up and sorry for the delay. No it's not intermittent, and I learned recently that if you run the PowerShell cmdlet again with the destroy switch, these settings will be rolled back anyway. At the time, based on my limited knowledge, deleting the repo with the gh commands just accelerates the cleanup of the GitHub side configuration, in case we have to cleanup if we are deploying to practice so we can perform subsequent deployments, so its really more of a convenient way to cleanup GitHub to prepare for other deployment attempts.