Bumps [@adobe/css-tools](https://github.com/adobe/css-tools) from 4.0.1 to 4.3.2.
- [Changelog](https://github.com/adobe/css-tools/blob/main/History.md)
- [Commits](https://github.com/adobe/css-tools/commits)

---
updated-dependencies:
- dependency-name: "@adobe/css-tools"
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…ure#3009)

* Make dashboard optional via name

* Formatting

* Formatting

* With insert final new line

* adding target for docker build

---------

Co-authored-by: Victor Vazquez <vhvb1989@gmail.com>

This restores the init behavior prior to 1.4.0 regression. `azd init` simply considers the current working directory when initializing, without attempting to resolve a parent directory project which is counterintuitive.

Fixes Azure#2946

Handle interrupt to unhide terminal cursor from a potentially active spinner

Azure#2194

Our intention is to use Azure RBAC to secure access to the container
registry, and the exchange our AAD token for a time limited access
token that we use to log into the registry. That has worked for some
users, but others have run into issues like what we see in Azure#2980

While we're still trying to root cause the actual issue, we have
discovered that if the admin account is enabled, the end to end
seems to work.

This change enables the admin account to allow `azd` to fall back to
that when the token exchange doesn't work.

Contributes To: Azure#2980

When publishing an .NET Application, you have two choices as to how to
reference the .NET Runtime.  You can either publish as a framework
dependent project, where your app will use a pre-deployed copy the
.NET Runtime, or self contained, where your app will care the .NET
Framework for your target platform with it.

Framework dependent projects are the default, because they are smaller
(you don't need to bring along an entire .NET runtime with your
application).

In Aspire, we were publishing as self contained because we needed the
latest and greatest version of the .NET Runtime, since there were some
breaking changes that impacted Aspire and it depended on, and the 
public base container images on MCR had `rc2` bits.

Now that .NET 8 has shipped, this is no longer a problem, and we can
publish as a framework dependent project once again. This results in
smaller container images, because they can leverage the shared
framework from the base container image instead of including yet
another copy of the runtime in the application layer.

)

* adding rg as variable for pipeline config

* azdo

…3071)

Avoid a panic and provide a better error message when containerPort is missing in binding. This is a runtime check for what should normally be handled at compile-time.

Related to: Azure#3070

As part of Preview 2, Aspire is adding support for a new resource,
`dockerfile.v0`. This represents an image that should be built (from a
Dockerfile) and deployed.

Consider the following AppHost:

```csharp
var builder = DistributedApplication.CreateBuilder(args);

builder.AddNodeApp("nodeapp", "../NodeApp/index.js")
    .WithServiceBinding(3000, scheme: "http", env: "PORT")
    .AsDockerfileInManifest();

builder.Build().Run();
```

The resulting manifest looks like this:

```json
{
  "resources": {
    "nodeapp": {
      "type": "dockerfile.v0",
      "path": "../NodeApp/Dockerfile",
      "context": "../NodeApp",
      "env": {
        "NODE_ENV": "development",
        "PORT": "{nodeapp.bindings.http.port}"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http",
          "containerPort": 3000
        }
      }
    }
  }
}
```

From a high level, these are very similar to `project.v0`
resources. The image needs to be built and pushed (either via `dotnet
publish` or `docker build` + `docker push`) and then we need to create
an Azure Container Apps App from it.

When doing `azd infra synth` we write the manifests for these types of
services in a `manifests` folder that is SxS with the
`Dockerfile`. This mimics the strategy for projects in spirit (where
we use the `.csproj` file as the "project" file)

Fixes an issue where if AZURE_ENV_NAME does not exist within the .env file then downstream operations will fail when looking up resource group or service names.

When we started the Aspire work, we thought we might only support
simple binding expressions with a single reference, e.g.:
`"{api.bindings.http.url}"`. Over time, this allow grew to allow
literals (e.g.: `"true"`). In Preview 2, the manifests now supports
multiple replacements in a single expression, to support things like
connection strings where you need multiple parts:
`"Host={api.bindings.tcp.host},Port={api.bindings.tcp.port}"`

To prepare for this, I've split the string evaluation logic from the
value resolution logic and then enhanced the string evaluation logic
to support more complex strings, while adding some tests to ensure
things behave as expected.

Upgrade dotnet base images to be based on bullseye.

Also, bump to 20131107.2 which is the current stable version and supports .NET 8.

Fixes Azure#3108

- Update all .NET samples and tests from .NET 6 to .NET 8 (latest LTS)

* changelog

* version file

* notes

---------

Co-authored-by: Victor Vazquez <vhvb1989@gmail.com>

Updating azure.yaml schema to support docker build target

Make "Retrieving locations..." ephemeral once again

Do not require `docker login` for Aspire apps

The `dotnet` toolchain is able to build and push container images for
Asprire apps via, `dotnet publish`. However, we still needed `docker`
around so we could run `docker login` to log into the private ACR
registry we intended to push the image to.

To remove the dependency on `docker login` we can use the
`SDK_CONTAINER_REGISTRY_UNAME` and `SDK_CONTAINER_REGISTRY_PWORD`
environment variables as described in:

https://github.com/dotnet/sdk-container-builds/blob/main/docs/RegistryAuthentication.md#authenticating-to-container-registries

The caveats here do not apply to us. If they did, we could consider
either editing the `~/.docker/config.json` directly, to add our auth
information or setting `DOCKER_CONFIG` when running `dotnet publish`
to a version that we write (just in time, in a temp dir) and clean up
after.

Note that the credentials fetched via the AAD flow are shortlived
(~3hr of validity) and so caching them in `~/.docker/config.json` long
term is less than ideal (our documentation for commands like `az acr
login` mention that you should do this before each operation).

---------

Co-authored-by: Wei Lim <weilim@microsoft.com>

This change relaxes the project detection logic during `azd init` to warn for projects unreferenced by the app host.

With this change, for dotnet app detection, we also exclude wasm based projects such as BlazorAssembly as hostable. These projects can be referenced by a Blazor server and act as a library.

Fixes Azure#3024

…ure#2992)

Enable more tests for recording. This should speed up PR builds by ~10 minutes.

Co-authored-by: Victor Vazquez <vhvb1989@gmail.com>

…zure#3125)

Reintroduce a `dependsOn` ordering that is required to avoid race conditions with updating `Microsoft.Web/sites/config` within the same deployment.

…ng instead of json (Azure#3130)

* use yaml marshall

This change adds supports for `inputs` which is a new (optional)
property on resources in the Aspire manifest. These inputs represent
values that deployment tools like `azd` need to provide "somehow".

For our initial support, we support string inputs which contain
metadata on how to generate a default value, based on a minumum random
length. Aspire uses this today to model passwords for cases like
`AddMySqlContainer()` where a deployment tool needs to provide a
password for the root user.

Consider the following AppHost manifest:

```json
{
  "resources": {
    "demoapp": {
      "type": "project.v0",
      "path": "../AspireContainers.DemoApp/AspireContainers.DemoApp.csproj",
      "env": {
        "ConnectionStrings__MySql": "{mysqlabstract.connectionString}"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http",
        }
      }
    },
    "mysqlabstract": {
      "type": "container.v0",
      "image": "mysql:latest",
      "env": {
        "MYSQL_ROOT_PASSWORD": "{mysqlabstract.inputs.password}"
      },
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "containerPort": 3306
        }
      },
      "connectionString": "Server={mysqlabstract.bindings.tcp.host};Port={mysqlabstract.bindings.tcp.port};User ID=root;Password={mysqlabstract.inputs.password}",
      "inputs": {
        "password": {
          "type": "string",
          "secret": true,
          "default": {
            "generate": {
              "minLength": 10
            }
          }
        }
      }
    }
  }
}
```

In this example, we spin up a MySql Container (with a randomly
generated password at least 10 characters long). The container
resource now has an expression with binding references in for its
`connectionString` property, and other resources (like `demoapp`) can
refer to this property to create connections to it.

To support this, we need to teach `azd` how to handle these inputs and
where to store them as well as decide how to the flow into both the
infrastructure and service deployments.

The strategy here for now is to model a new `Inputs` object, which
holds all the values for the given inputs. The object contains a top
level key for every resource with an input and the value is an object
that maps inputs from that resource to their values, eg:

```json
{
  "mysqlabstract": {
     "password": "<value-from-deployment-tool>"
  }
}
```

For bicep deployments, you can mark an object or secure object
parameter with `@metdata(azd: { type: 'inputs' } )` the value will be
passed as this object.

For container app deployments, the new `Inputs` field is present on
the root context object and you can read values from this map.

These are stored in the environment config (so they can vary per
environment) under the "inputs" section.

Values which are marked as `secure` today are not encrypted at rest,
but this is something we will improve before GA, by storing these
values in KeyVault and then reference from there.

We do, however, mark the parameter that gets the value in the bicep
deployment as an `@secure()` parameter, so the values like passwords
are not retained in the deployment log.

As part of this change, some small improvements where made to the
binding expression evaulatior, to allow using `.host` in references to
container apps (we know the value will be the same as the container
app name, due to how networking works in ACA).

Fix the generation logic: emit a log analytics workspace when a container apps environment is required.

Remove the dependency of container registry on log analytics workspace since that is actually extraneous based on the bicep template/

Fixes Azure#3141

Increase resiliency of devcontainer install scripts for function tools:

- Install under `/opt/microsoft/azure-function-core-tools`
- Symbolic link just `func` instead of installing binaries into `/usr/bin`

* update runtime version

* update incompatible packages

Bumps [golang.org/x/crypto](https://github.com/golang/crypto) from 0.14.0 to 0.17.0.
- [Commits](golang/crypto@v0.14.0...v0.17.0)

---
updated-dependencies:
- dependency-name: golang.org/x/crypto
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…skip auto-browser opening. (Azure#3096)

…e#3163)

* association for .bicept as go-template and extension for syntax

* net aspire - support cosmos db

* remove new line

This enables the admin user on the provisioned container registry so
that `azd` can connect to it to push even if RBAC is not working
because the user is not an owner of the resource.  We've seen cases
where users who's accounts where created a long while back are set as
[classic administrators](https://learn.microsoft.com/en-us/azure/role-based-access-control/classic-administrators)
and not Owners on their accounts and there is presently a service issue
that prevents these users from exchanging their AAD creds for an
access token.

Fixes Azure#3157

* feat: add gha schema lint

* checkout v4 and remove pull-requests permission

Bumps [follow-redirects](https://github.com/follow-redirects/follow-redirects) from 1.15.2 to 1.15.4.
- [Release notes](https://github.com/follow-redirects/follow-redirects/releases)
- [Commits](follow-redirects/follow-redirects@v1.15.2...v1.15.4)

---
updated-dependencies:
- dependency-name: follow-redirects
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>