Enable azure test github-action

[jshiwamV]

• also fix changed files filtering logic while running the github action for long running tests.
• Please check the comments in the relavant sections to know more details about the changes.

[jshiwamV]

ack, i have found some bugs in azure, i am fixing it as a part of same pr. Those bugs popped up while running the test on github actions.

[jshiwamV]

Both Resource[Microsoft.Authorization/roleAssignments:RoleDefinitionId and data.azurerm_role_definition.owner.id are not GUID. The RoleDefinitionId looks like the one in following response

{
 
  "id": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleAssignments/00000000-0000-0000-0000-000000000000",
  "roleDefinitionId": "/subscriptions/11111111-1111-1111-1111-111111111111/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
  "roleDefinitionName": "Contributor",
  "scope": "/subscriptions/11111111-1111-1111-1111-111111111111",
  "type": "Microsoft.Authorization/roleAssignments"
}

Reference: https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments#role-assignment

This doc is a bit confusing, since in one of the examples the roleDefinitionID is a Guid, while in other one its a full Path just like the above one.

[jshiwamV]

any_modified returns true, when any other files instead of ignored ones are changed, that is when we want to run the tests. Filtering helps us to avoid long running tests when it's not needed

[jshiwamV]

Security rules are evaluated and applied based on the five-tuple information of source, source port, destination, destination port, and protocol.

Ref : https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview
if a security group rule doesn't match then Azure looks for lower priority rule. As per the default security group rules the above rule was redundant since, if it didn't match then the default rule would allow the inbound access via load-balancer. We filter out the traffic at the loadbalancer level currently in two ways

resource "kubernetes_service" "console_load_balancer" {
  metadata {
    name      = "mz${var.resource_id}-console-lb"
    namespace = var.namespace
    annotations = {
      "service.beta.kubernetes.io/azure-load-balancer-internal" = var.internal ? "true" : "false"
    }
  }

  spec {
    type                        = "LoadBalancer"
    external_traffic_policy     = "Local"
    load_balancer_source_ranges = var.internal ? null : var.ingress_cidr_blocks
    selector = {
      "materialize.cloud/name" = "mz${var.resource_id}-console"
    }
    port {
      name        = "http"
      port        = var.materialize_console_port
      target_port = 8080
      protocol    = "TCP"
    }
  }

  wait_for_load_balancer = true

  lifecycle {
    ignore_changes = [
      # The resource_id is known only after apply,
      # so terraform wants to destroy the resource
      # on any changes to the Materialize CR.
      metadata[0].name,
      spec[0].selector["materialize.cloud/name"],
    ]
  }
}

1. If the loadbalancer is public then we restrict traffic via load_balancer_source_ranges.
2. LoadBalancer only accepts traffic on certain port which is already configured.

Hence the security group rule didn't serve any useful purpose.