-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Issue] [aspire] azd infra synth
ignored by azd deploy
in azdo ci/cd pipeline
#3891
Comments
I was trying to follow the workaround for |
@Bpflugrad To confirm your findings:
|
same as #3850 please see: #3850 (comment) . |
Hi @Bpflugrad. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “ |
Hi @vhvb1989, While my goal to get the secured value to work in deployment pipelines is the same, this seems like a distinct issue where the Doesn't seem like a duplicate request. Big thanks for your info on #3850 though! Didn't mean for this to be terse. |
@Bpflugrad , thank you for your follow up. There is indeed, an issue. Then, when azd runs on CI/CD, if the pipelines uses linux, azd is not transforming the path to a linux path, so it is not finding the /infra folder in the appHost and the synthetized yaml files; so it is generating them from the project. Seems like a regression after moving the yaml files from each individual service path, to an infra folder in the AppHost. Since you were manually updating the yaml files before and that was working for you, I think this is a regression on azd. @ellismg |
But it does feel like this decision doesn't play well with the fact that even if you are on Windows, CI is likely Linux. I think we should just ensure we allow using This feels in line with the aspire manifest, which uses
|
Since we expect an `azd` project to be used across operating systems which use `/` and `\` as path seperators, we need a common way of writing paths in `azure.yaml` that works across both. In the path we supported using both `\` and `/` in `azure.yaml` (and went out ouf or way in the Aspire case to write the platform specific version during `init`) but in some cases this would lead to weird behavior when you then puth the project into GitHub actions and *nix runners would look for files that may not exist, due to the path seperator. To address this, we update our `ProjectConfig` yaml parsing and saving to assume forward slash seperated paths, and then use `filepath.FromSlash` and `filepath.ToSlash` on the boundaries. This means the data stored at runtime inside `ProjectConfig` is using the correct platform seperator, but when being saved to disk, we always use `/`. To support backwards compatability, for paths which have only `\` and no `/`, we treat as if they were written with `/` instead of `\` (and we will fix them up if we end up rewrting azure.yaml). Fixes Azure#3891
Since we expect an `azd` project to be used across operating systems which use `/` and `\` as path seperators, we need a common way of writing paths in `azure.yaml` that works across both. In the path we supported using both `\` and `/` in `azure.yaml` (and went out ouf or way in the Aspire case to write the platform specific version during `init`) but in some cases this would lead to weird behavior when you then puth the project into GitHub actions and *nix runners would look for files that may not exist, due to the path seperator. To address this, we update our `ProjectConfig` yaml parsing and saving to assume forward slash seperated paths, and then use `filepath.FromSlash` and `filepath.ToSlash` on the boundaries. This means the data stored at runtime inside `ProjectConfig` is using the correct platform seperator, but when being saved to disk, we always use `/`. To support backwards compatability, for paths which have only `\` and no `/`, we treat as if they were written with `/` instead of `\` (and we will fix them up if we end up rewrting azure.yaml). Fixes Azure#3891
Since we expect an `azd` project to be used across operating systems which use `/` and `\` as path seperators, we need a common way of writing paths in `azure.yaml` that works across both. In the path we supported using both `\` and `/` in `azure.yaml` (and went out ouf or way in the Aspire case to write the platform specific version during `init`) but in some cases this would lead to weird behavior when you then puth the project into GitHub actions and *nix runners would look for files that may not exist, due to the path seperator. To address this, we update our `ProjectConfig` yaml parsing and saving to assume forward slash seperated paths, and then use `filepath.FromSlash` and `filepath.ToSlash` on the boundaries. This means the data stored at runtime inside `ProjectConfig` is using the correct platform seperator, but when being saved to disk, we always use `/`. To support backwards compatability, for paths which have only `\` and no `/`, we treat as if they were written with `/` instead of `\` (and we will fix them up if we end up rewrting azure.yaml). Fixes Azure#3891
Output from
azd version
Run
azd version
and copy and paste the output here:azd version 1.9.0 (commit 651394c3ddcfadff194d177f8b0ddf06fe3752bf)
Describe the bug
azd infra synth
has been executed, and the generated templates in the AppHost project are committed and pushed to the build branch, butazd deploy
generates theinfra
itself, ignoring any manual changes.To Reproduce
azd init
state: remote: backend
for remote configuration.azd pipeline config
azconnection
service principal withStorage Blob Contributor
on your remote configuration blob storage.AddConnectionString
inAppHost
.AddReference
on theApiService
resource.Aspire.Azure.Storage.Blobs
toApiService
.azd env set AZURE_BLOB_STORAGE_CONNECTION ""
to add string to env.azd infra synth
apiservice.tmpl.yaml
to replace'{{ securedParameter "BlobStorageConnection" }}'
with{{ .Env.AZURE_BLOB_STORAGE_CONNECTION }}
main.bicep
to add output AZURE_BLOB_STORAGE_CONNECTION string = BlobStorageConnectionBuild will fail at
azd deploy
with message:ERROR: failed deploying service 'apiservice': failing invoking action 'deploy', failed executing template file: template: containerApp.tmpl.yaml:21:19: executing "containerApp.tmpl.yaml" at <securedParameter "BlobStorageConnection">: error calling securedParameter: parameter BlobStorageConnection not found
This indicates that
securedParameter "BlobStorageConnection"
is still in the template. Note thatcontainerApp.tmpl.yaml
is the file name, which was the file name fromazd 1.8.2
.Log message indicates that new template was generated, not the one created by
azd infra synth
:2024/05/09 23:45:47 service_target_dotnet_containerapp.go:195: generating container app manifest from /home/vsts/work/1/s/.\AspireInfraExample.AppHost\AspireInfraExample.AppHost.csproj for project apiservice
Expected behavior
Infra created by
azd infra synth
should be used.Environment
Information on your environment:
- dotnet 8.0.300-preview.24203.14
- Version 17.10.0 Preview 7.0
- azd version 1.9.0 (commit 651394c)
Additional context
Complete
azure.yaml
:Complete
azure-dev.yaml
:The text was updated successfully, but these errors were encountered: