Pipeline generated through `azd pipeline config` fails with `mvnw: permission denied`

[zzhxiaofeng]

Describe the issue: Logs is fail when run pipeline test in github and azure devops in windows.

Repro Steps: Run command: azd pipeline config or azd pipeline config --provider azdo and verify logs is passed succesfully or not.

Error Message:

Environment: OS: Windows desktop Template: https://github.com/Azure-Samples/todo-java-mongo Branch: staging

Expected behavior: logs is passed succesfully when run pipeline test in github and azure devops.

@weikanglim for notification.

[weikanglim]

Hi @zzhxiaofeng can you share:

1. The repository you cloned the template into
2. The build pipeline that has the failure

The issue is likely that the mvnw script doesn't have executable script set. I'm still trying to dig deeper.

[weikanglim]

I was able to reproduce the issue now. Also important to mention, this works correctly on Linux, or when using the Use this template feature on GitHub.

The issue is that when a user uses azd init to clone the template on Windows:

1. We clone the repository using git (which executable bit permissions are stored in git)
2. We then delete the git repository (since azd init is meant for template download). This deletes all permission information that stored in git.
3. When we run azd pipeline config, this creates a new git repository. However, the previous executable bit permissions are now gone.

The workaround fix would be: Run on your local Windows desktop: git update-index --chmod=+x src/api/mvnw && git commit -m "Fix executable bit permissions" && git push.

This sets the executable bit permissions and stores it in Git. When the pipeline runs, the permissions will be restored correctly.

Why this happens: The general issue is not specific to Java. When azd init runs, we lose executable bit permissions on all files downloaded if running on Windows. Linux is not affected as the permissions are stored with the filesystem.

How azd could fix this: Make azd init ensure it runs inside a git repository, either by creating a git repository, or require running in an existing git repository. Then, we can always ensure the executable bit is restored.

[vhvb1989]

great finding @weikanglim

Should we just run something like git remote remove origin instead of deleting the .git folder? The only thing we want is to break the origin

[zedy-wj]

@weikanglim - Thank you for your help! We tried to execute git update-index --chmod=+x src/api/mvnw && git commit -m "Fix executable bit permissions" && git push after creating a new git repository with command azd pipeline config, and this issue can be fixed. Following this approach above, the azd pipeline config command will fail first. After adding the executable bit permissions, the execution is successful. It's duplicate, and we are doing automated testing on azd pipeline config. Is there a better way to resolve this issue?

[weikanglim]

great finding @weikanglim

Should we just run something like git remote remove origin instead of deleting the .git folder? The only thing we want is to break the origin

@vhvb1989 Yes, that is the spirit of the solution, although we'd have to be more careful in rewriting the initial commit message, and pruning leftover git objects that could be around. But the main resulting behavior is that azd init now creates a git repository whereas previously it just downloaded the template files -- which is the thing I'm looking for feedback on.

[weikanglim]

@zedy-wj I don't think the workaround is ideal either, but it's a bug in azd init that requires a feature change and thus needs further discussion. Alternatively, azd pipeline config will succeed if ran on Linux instead of Windows

[rajeshkamal5050]

@weikanglim so should we document this as a known issue with workarounds for November release?

[weikanglim]

@rajeshkamal5050 Yes, given it's a small issue with a known one-line workaround, azd init creating a git repository is a feature that needs discussion.

@savannahostrowski as FYI -- TL;DR: Java templates, when cloned on Window, requires an additional workaround step for the CI pipeline generated by azd pipeline config (which runs on Linux) to succeed. Recommend documenting it somewhere as part of the release

[savannahostrowski]

cc: @puicchan for docs on this known issue for the November release.

[puicchan]

@weikanglim, can you provide the verbiage to @hhunter-ms so we can get this updated? Created an issue to track this: https://github.com/Azure/azure-dev/issues/953

[zedy-wj]

@rajeshkamal5050, @puicchan - We see this issue being tracked to #953, and #953 has been closed. So we re-tested based on the latest daily version( azd version 0.4.0-beta.1-daily.1965526 (commit e2b43ea79ca6642946ae10227156cc5a88d861f2) ) of azd, but this issue still exists, what is the current situation?

[rajeshkamal5050]

@v-xuto @zedy-wj have you tried this documented workaround? https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/troubleshoot#azd-pipeline-config-using-azdo-for-java-templates-on-windows

cc: @weikanglim

[v-xuto]

@v-xuto @zedy-wj have you tried this documented workaround? https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/troubleshoot#azd-pipeline-config-using-azdo-for-java-templates-on-windows

@rajeshkamal5050 It can run successfully through the manual steps in this document.