project: Use / as path seperator in azure.yaml
#4263
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jongio
reviewed
Aug 28, 2024
ellismg
commented
Aug 28, 2024
|
@vhvb1989 I didn't yet validate that this addresses the issue in GitHub, but based on what I understood from your investigation, it seemed like this is what we might want. Are you able to take the privates here and see if this addresses the issue as you understood it? |
|
Worked on my end.
Thank you @ellismg |
vhvb1989
approved these changes
Aug 29, 2024
ellismg
force-pushed
the
ellismg/fix-3891
branch
from
7f90091 to
83bcce9
Compare
weikanglim
approved these changes
Aug 30, 2024
wbreza
approved these changes
Aug 30, 2024
wbreza
reviewed
Aug 30, 2024
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
ellismg
force-pushed
the
ellismg/fix-3891
branch
from
83bcce9 to
f6c53c3
Compare
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since we expect an
azdproject to be used across operating systems which use/and\as path seperators, we need a common way of writing paths inazure.yamlthat works across both. In the path we supported using both\and/inazure.yaml(and went out ouf or way in the Aspire case to write the platform specific version duringinit) 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
ProjectConfigyaml parsing and saving to assume forward slash seperated paths, and then usefilepath.FromSlashandfilepath.ToSlashon the boundaries. This means the data stored at runtime insideProjectConfigis 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 #3891