The `dotnet` tool has native support for producing (and pushing) a
container image. This does not require a local docker daemon and in
general "does the right thing" and is the prefered way for .NET
customers to produce container
images. https://learn.microsoft.com/dotnet/core/docker/publish-as-container
gives a good overview of how this support works and we've been using
it to build and push container images for Aspire apps.
This change updates things such that we can use this support when
building a non Aspire based .NET app. If a `Dockerfile` exists, we
respect it, but otherwise instead of trying to use Oryx to produce a
container image, we will use `dotnet publish`.
In addition, we now use 8080 as the default port of a `dotnet` based
application (with no Dockerfile) as that's the default port used by
the standard ASP.NET base image.
A new recorded test was added - it builds on top of the existing
`containerapp` sample, and the test aranges to remove the `Dockerfile`
file from the template before running `up`.
Fixes#2632Fixes#4583
We should be able to re-enable the tests now. The one exception is the
`azd login` test that validated login with a long lived client secret,
since we no longer have a service principal with a long lived client
secret.
We'll have to make due without the end to end coverage here - but in
practice we have good coverage at the unit test level of much of the
code here, so we should be okay.
Contributes To #4564
The current version that is installed on the runners (0.31.34) has
some bugs around linting and causes lint warnings during our
legs. These errors are not present on the latest Bicep CLI.
Force an upgrade of the binary that is installed as part of the test
runner to latest version. We should be able to remove this step once
new image is built with an upgraded bicep (the `README.md` at
https://github.com/actions/runner-images/tree/main/images/ubuntu has
information about what is on the runner.)
* service hooks
* As part of merging azd operation and hooks, this PR allows users to define hooks outside of azure.yaml as individual files with the name azd.hooks.[yaml | yml].
The file can be placed in the /infra folder for project level hooks or inside service's folder for service level hooks.
This will allow generators like Aspire to include hooks as part of the infrastructure code (w/o touching azure.yaml). Then, when running azd infra synth, the hooks are part of the infrastructure and users can delete the infra folder to go back to full Aspire in-memory generation w/o touching azure.yaml.
After this PR, I am planning to move the azd operations to become a valid built-in hook and delete the alpha feature for azd operations and the entire feature in favor of just using the hooks strategy
Now that `azd` supports OIDC in Azure Pipelines via #4343, let's use
it in the `build-cli` leg of CI. Since we now use OIDC, we can also
migrate to the TME environment for the resources created during our
tests, by using the new `azd-service-connection` service connection.
In addition to the build authoring updates, I needed to make some
small changes to the integration testing framework and recording
framework to get these changes to work when running in playback mode.
I added `AZD_DEBUG_LOGIN_FORCE_SUBSCRIPTION_REFRESH` which can be used
to force `azd login` to load (and cache) subscriptions when you log
in. This refresh does not usually happen for service principal based
logins, but we want it to happen here so that the subscription list
can be served from cache instead of hitting the `/subscriptions`
endpoint of ARM to list subscriptions in each test (and record the
result). This also ensures the environment during playback is a bit
closer to the one like a developer will have when hacking on `azd`
(since they too will have run `azd login` locally thus primed their
subscription cache).
Moving to the TME user also exposed an issue with `azd` during
playback if the list of subscriptions the user has does not include
the subscription that was used for a recorded test. In this case,
`azd` could end up trying to fetch information about this
subscription, leading to test failures because this generates requests
that don't have recorded interactions. To work around this issue, I've
added a new `AZD_DEBUG_SYNTHETIC_SUBSCRIPTION` environment variable
that can be set to a subscription ID. When set, the
`SubscriptionManager` ensures the list of subscriptions returned by
`GetSubscriptions` includes an entry for this subscription. The
integration test framework arranges for this value to be set during
playback. This allows the rest of the test to work (the fact that the
principal running the test doesn't have access to the subscription
used for the recording ends up not mattering, since we serve all
requests from the recordings instead of against live Azure).
Finally, we needed to add the endpoint that is used inside Azure
DevOps to fetch the ID token during the OIDC flow to the list of URLs
that the recording infrastructure that should not be recorded.
With this change, the `azd-login` step is no longer used across any
pipelines, so we can remove it.
Fixes#4341Fixes#4501
`add` command that adds resource configuration to `azure.yaml`.
In this experience, users are able to proceed with running `provision` or `up` after committing the `azure.yaml` change.
Contributes to #4397, https://github.com/Azure/azure-dev-pr/issues/1682
Fix some errors found in scenario: frontend + backend + mongodb.
1. Use 'cosmos.outputs.exportedSecrets' to specify the relationship between cosmos and ACA.
2. Upgrade cosmos to '0.8.1' to use 'cosmos.outputs.exportedSecrets'.
3. Move 'name' and 'location' to the frontend of params to keep align with other modules.
4. Add 'networkRestrictions' to make cosmos can be accessed in public network.
5. Use 'secretsExportConfiguration' instead of 'secretsKeyVault' to meet the new version of cosmos.
6. Delete 'dependsOn'.
7. Use '*' to allow all http methods.
Surface "Create a minimal project" as a main menu option in `init`.
This moves the initializing a minimal project flow from "Initialize a template -> Minimal" to "Create a minimal project".
When compose is enabled, only a project file is generated. When compose is not enabled, the previous functional behavior is retained -- no UX changes made.
Contributes to #4397, https://github.com/Azure/azure-dev-pr/issues/1682
This change reworks the `test-templates` test legs to use OIDC and
move to our TME subscription.
To do so, we capture the relevent `AZURESUBSCRIPTION_` environment
variables that are set by the AzureCLI task and then flow them into
the dev container when we run tests. This allows us to do `azd auth
login` inside the devcontainer but still use OIDC so we don't have a
long lived secret.
The call to `az login` was removed because we don't yet have a way to
have this work well with ODIC in the container. This means the
terraform flavor of the tests won't work (since auth is broken) but
these legs have been broken in both the bicep and terraform flavors
for a while, so this moves us in a better direction (and gets us off
of client secrets and onto TME for these tests).
Contributes To #4341
In addition to the `IsAspireHost` property we will now look at the
project capabilities to see if an `Aspire` capability is listed and if
treat the project as an AppHost project. This aligns `azd`'s behavior
with other tooling like Visual Studio which uses the project
capabilities to determine if the project is an App Host or not.
The .NET Team asked us to include this in our sniffing logic (but to
continue to check `IsAspireHost` as well).
Fixes#4364
This change adds `azure-pipelines` as a supported value for the
`--federated-credential-provider` switch of `azd auth login`. This
provider can be used to do OIDC based login within the context of a
job running in Azure Pipelines.
When using this provider, `azd` uses the `AzurePipelinesCredential`
type to manage the OIDC dance. In addition to the client and tenant id
of the service principal you plan to authenticate with, we also need
the "service connection id" (this is the ID of the object created in
Azure Pipelines that contains the connection information) and the
system access token which is the security token for the running build
(it's what is used to authenticate to the OIDC endpoint that is being
run inside the pipeline which we use to fetch the federated
credential). The client and tenant ids can be provided on the command
line, via the existing `--client-id` and `--tenant-id` switches, or,
when `azure-pipelines` is the `federated-credential-provider`, they
can be read from the `AZURESUBSCRIPTION_CLIENT_ID` and
`AZURESUBSCRIPTION_TEANT_ID` system environment varaibles. The
service connection ID and acceess token are read from the
`AZURESUBSCRIPTION_SERVICE_CONNECTION_ID` and `SYSTEM_ACCESSTOKEN`
environment variaibles.
These system environment variables correspond to what the `AzureCLI@2`
sets when passing the `azureSubscription` parameter (after translating
the service connection name to a service connection ID, which is
handy) allowing something like this to work:
```yaml
- task: AzureCLI@2
inputs:
azureSubscription: azconnection
scriptType: bash
scriptLocation: inlineScript
inlineScript: |
azd auth login --federated-credential-provider "azure-pipelines"
azd up
```
Note that while the AzureCLI task is used above, it's only used for
setting these environment variables and doing the service connection
name to id translation. You could do something like the following
instead:
```yaml
- bash: |
azd auth login --federated-credential-provider "azure-pipelines"
azd up
env:
AZURE_SUBSCRIPTION_CLIENT_ID: "Your Client ID"
AZURE_SUBSCRIPTION_TENANT_ID: "Your Tenant ID"
AZURE_SUBSCRIPTION_SERVICE_CONNECTION_ID: "Your Service Connection ID"
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
```
And things will work as well. This can be useful in cases where you
can use the `AzureCLI@2` task directly.
We can consider writing our own task as some point as well.
Contributes To #4341
Per https://learn.microsoft.com/dotnet/core/tools/dotnet-environment-variables#dotnet_nologo:
> Specifies whether .NET welcome and telemetry messages are displayed
on the first run. Set to true to mute these messages (values `true`,
`1`, or `yes` accepted) or set to false to allow them (values
`false`, `0`, or `no` accepted). If not set, the default is `false`
and the messages will be displayed on the first run.
Since there are cases where we interpret the output of the `dotnet`
CLI (for example, when calling `dotnet msbuild
--getProperty:IsAspireHost`) we should set this value to ensure that
this message is not printed, which would break our deserialization
logic, which expects just JSON data to be printed to stdout.
Fixes#4513
Resolves#3958
This update moves away from manually reading Azure deployment outputs to leveraging the Outputs API directly from the ADE team. This enables a seamless outputs experience across their supported runners including ARM, Bicep, Terraform and other custom runners.
Add functionality for YAML node manipulation using dotted-path syntax.
This will be used in upcoming work that is aimed to manipulate YAML nodes to preserve comments, multi-line strings, and provide consistent formatting options for users.
Refactoring port prompting in infra_confirm.go
These changes are being teased out to reshare implementation across alpha-enabled vs regular code pathways.
* Changed golangci-lint feature to updated repo
* remove the golangci-lint specific feature
* removed golangci-lint feature in light devcontainer
---------
Co-authored-by: Pablo Zaidenvoren <pablozaiden@users.noreply.github.com>
Refactor to integrate alpha switch for composability for a cleaner landing in the upcoming feature change.
In the upcoming feature change, we would want `azd init` without composability alpha feature enabled to continue materializing infrastructure as-is. If composability is enabled, we would want to hold the infrastructure in-memory.
This change refactors infra generation logic into a new method.
To set up a cleaner future diff, we also add alpha feature manager as a dependency of the infra generator.
With this change, we switch easy-init's generated infrastructure to use avm (Azure Verified Modules).
Since AVM allows us to express resource definitions in a more condensed form, we employ the strategy of having a single ` resources.bicep` that uses all the different modules available is employed.
Notable behavioral changes introduced:
**Postgres**
- Server version upgraded from version 13 to version 15.
- Storage size reduced from 128GB to 32GB (AVM default).
**MongoDB**
- Server version upgraded from 4.0 to 4.2.
**Redis**
- Redis is now implemented as an Azure Cache for Redis instance instead of previously as a container app image.
Environment variables are also standardized:
- POSTGRES_URL, MONGODB_URL, REDIS_URL all serves as the full connection string URI to the respective instances.
Contributes to: https://github.com/Azure/azure-dev-pr/issues/1682
Fix help text for `azd template source add`
- Short no longer has multiline text
- Replaced 'http://aka.ms/awesome-azd' with 'https://aka.ms/awesome-azd'
---------
Co-authored-by: Wei Lim <weilim@microsoft.com>
* use label as package out of repository and re-use for apphost project generation
* use names
* use GetDefaultProjectName
* fix `show` not using project name as AppName
* refactor as a function
* clean up one spot
* add copyright notice
* remove panic
---------
Co-authored-by: Wei Lim <weilim@microsoft.com>
Use the `EXPOSE` directives in a Dockerfile to default the port configuration for the service.
- When multiple `EXPOSE` ports are present, we will prompt the user for port selection.
- When no Dockerfile or `EXPOSE` is present, the user will be asked as usual to provide a port number.
Completes #4443
Daniel Jurek
Azure SDK Bot
Matt Ellis
Victor Vazquez
Rujun Chen
Wei Lim
Wallace Breza
Pablo Zaidenvoren
Alex Weininger
alexwolfmsft
dependabot[bot]
Rujun Chen