Closed alvaradojl closed 1 year ago
Thank you @alvaradojl for reporting this.
Did you run the setup.sh
script first before running run.sh
? If so, what was the output?
@1liveowl yes and it ran succesfully, just like with the Identity Framework setup.
Setting up the deployment environment. Settings execute permissions on necessary scripts files. Building the deployment container. [+] Building 1.5s (10/10) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 38B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/ubuntu:22.04 1.4s => [1/6] FROM docker.io/library/ubuntu:22.04@sha256:dfd64a3b4296d8c9b62aa3309984f8620b98d87e47492599ee20739e8eb5 0.0s => CACHED [2/6] RUN apt-get update && apt-get install -y curl dnsutils python3-pip jq sudo 0.0s => CACHED [3/6] RUN curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/s 0.0s => CACHED [4/6] RUN pip3 install ruamel.yaml 0.0s => CACHED [5/6] WORKDIR /asdk 0.0s => CACHED [6/6] RUN git config --global --add safe.directory /asdk 0.0s => exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:44d32ef004a9f78e69e2dd50f01364f0e65132e9345f544816ba47657c8bcd32 0.0s => => naming to docker.io/library/asdk-script-deployment:latest 0.0s Setting up log folder...
Setup complete. You can now run the deployment script using the command './run.sh'.
Not sure if useful, but I'm running from a WSL terminal (Ubuntu 22.04): AZ CLI 2.48.1 GH CLI 2.29.0 Running from the latest version of main branch.
And you forked the repo first, right? You have to run it as a fork to your own repo and then clone it from your own fork.
yes, I'm running from my own forked repo
Not sure if useful, but I'm running from a WSL terminal (Ubuntu 22.04): AZ CLI 2.48.1 GH CLI 2.29.0 Running from the latest version of main branch.
This looks correct
I'm assuming that your are running WSL 2.0.
The issue is related to this line of bash code:
"${SHARED_MODULE_DIR}/map-output-parameters-for-app-service.py" \
"${APP_NAME}" \
"${BICEP_IDENTITY_FOUNDATION_OUTPUT_FILE}" \
"${BICEP_APP_SERVICE_DEPLOY_PARAMETERS_FILE}" \
"${CONFIG_FILE}" | ...
You'll find the variables referenced there in the file <your github base folder>/azure-saas/src/Saas.Lib/Deployment.Script.Modules/app-service-constants.sh
.
My best guess is that the script running inside the container is denied permission to one of the paths defined by these variables. Why I'm not sure.
Does this ring any bells?
It does, have you managed to reproduce it?
It does, have you managed to reproduce it?
No. Unfortunately not. I will have to dig deeper to understand why you are seeing this and we're not.
Could you try an put a # right after bash in the last line of the run.sh script? This will open a prompt in the container w/o running the script. From this prompt could you try and access the paths?
this is what i get when i run only the bash as entry point and then navigating to
/asdk/src/Saas.Identity/Saas.Permissions/deployment
and running start.sh
root@57db6e21e66d:/asdk/src/Saas.Identity/Saas.Permissions/deployment# ./start.sh
fatal: not a git repository (or any parent up to mount point /asdk/src/Saas.Identity/Saas.Permissions)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
/asdk/src/Saas.Identity/Saas.Permissions/deployment/constants.sh: line 35: /src/Saas.Lib/Deployment.Script.Modules/app-service-constants.sh: No such file or directory
./start.sh: line 15: /src/Saas.Lib/Deployment.Script.Modules/config-module.sh: No such file or directory
./start.sh: line 16: /src/Saas.Lib/Deployment.Script.Modules/log-module.sh: No such file or directory
./start.sh: line 17: /src/Saas.Lib/Deployment.Script.Modules/user-module.sh: No such file or directory
./start.sh: line 23: CONFIG_FILE: unbound variable
But files seem to be there:
root@57db6e21e66d:/asdk/src/Saas.Lib/Deployment.Script.Modules# ls -l
total 164
-rw-r--r-- 1 1000 1000 2933 May 11 08:56 act-credentials-module.sh
-rw-r--r-- 1 1000 1000 14536 May 11 08:56 app-reg-module.sh
-rw-r--r-- 1 1000 1000 1299 May 11 08:56 app-service-constants.sh
-rw-r--r-- 1 1000 1000 1828 May 11 08:56 backup-module.sh
-rw-r--r-- 1 1000 1000 599 May 11 08:56 clean-credentials.sh
-rw-r--r-- 1 1000 1000 254 May 11 08:56 colors-module.sh
-rw-r--r-- 1 1000 1000 13258 May 11 08:56 config-module.sh
-rwxr-xr-x 1 1000 1000 1960 May 11 08:56 deploy-app-service.sh
-rw-r--r-- 1 1000 1000 1997 May 11 08:56 deploy-config-entries.sh
-rw-r--r-- 1 1000 1000 637 May 11 08:56 deploy-debug.sh
-rw-r--r-- 1 1000 1000 1703 May 11 08:56 deploy-service-module.sh
-rw-r--r-- 1 1000 1000 3087 May 11 08:56 github-module.sh
-rw-r--r-- 1 1000 1000 6718 May 11 08:56 key-vault-module.sh
drwxr-xr-x 2 1000 1000 4096 May 11 08:56 linux-ubuntu
-rw-r--r-- 1 1000 1000 4327 May 11 08:56 log-module.sh
drwxr-xr-x 2 1000 1000 4096 May 11 08:56 macos
-rw-r--r-- 1 1000 1000 2297 May 11 08:56 map-output-parameters-for-app-service.py
-rw-r--r-- 1 1000 1000 1254 May 11 08:56 oidc-workflow-module.sh
-rw-r--r-- 1 1000 1000 1122 May 11 08:56 patch-github-workflow.py
-rw-r--r-- 1 1000 1000 4680 May 11 08:56 policy-module.sh
-rw-r--r-- 1 1000 1000 1478 May 11 08:56 resource-module.sh
-rw-r--r-- 1 1000 1000 11990 May 11 08:56 service-principal-module.sh
-rw-r--r-- 1 1000 1000 6607 May 11 08:56 storage-module.sh
-rw-r--r-- 1 1000 1000 5639 May 11 08:56 tenant-login-module.sh
-rw-r--r-- 1 1000 1000 4828 May 11 08:56 user-module.sh
-rw-r--r-- 1 1000 1000 7974 May 11 08:56 util-module.sh
@1iveowl would it be possible that it doesn't work as expected when the github repo is private?
I noticed that the run.sh
copies the entire .git
directory. Just a thought....
When I noticed this error:
root@cf97a5da5b74:/asdk/src/Saas.Identity/Saas.Permissions/deployment# ./start.sh
fatal: not a git repository (or any parent up to mount point /asdk/src/Saas.Identity/Saas.Permissions)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Then I updated the start.sh
and right before line 61 I added git init
Which then gave me an error that it could not find the bicep files:
cp: cannot stat '/asdk/src/Saas.Identity/Saas.Permissions/deployment/Bicep/Parameters/parameters-template.json': No such file or directory
I noticed that there were two folders: Bicep and bicep in the Saas.Permissions/deployment directory and the file app-service-constants.sh
had the following settings:
# local bicep script directory
BICEP_DIR="${BASE_DIR}/Bicep"
BICEP_PARAMETERS_DIR="${BASE_DIR}/Bicep/Parameters"
which I changed to
BICEP_DIR="${BASE_DIR}/bicep"
BICEP_PARAMETERS_DIR="${BASE_DIR}/bicep/Parameters"
Then i noticed the error is still there because in fact there is no file in the project with the path Saas.Permissions/deployment/bicep/Parameters/app-service-parameters.json
So I guess someone forgot to check them in?
Thank you. This is interesting. Please allow me to investigate a bit further. I don't recall if this file is supposed to be part of the repo or something that is generated by the script.
I can't look at this today. But I will look at it tomorrow.
I think I found the root problem:
docker run \
--interactive \
--tty \
--rm \
--volume "${host_deployment_dir}":"${container_deployment_dir}":ro \
...
The host_deployment_dir cannot be read-only because it's also the path for the bicep parameter file (which as you mentioned is generated dynamically).
So removing :ro did the job, as so:
docker run \
--interactive \
--tty \
--rm \
--volume "${host_deployment_dir}":"${container_deployment_dir}" \
After this change, the run.sh
completed succesfully.
I've looked at this and there was some inconsistencies in the naming that have now been fixed: https://github.com/Azure/azure-saas/commit/4d793effb72482be4868c3dc66fd69453e54d980.
Unfortunately, I've not have had the opportunity to test it end-to-end yet, as I currently do not have access to a test environment. I will do this later.
My guess is that you've uncovered this issue/bug because you are cloning your repo to a directory within your WSL. If you clone it to a Windows directory and accessing it from WSL using /mnt/<drive-name>/path
, the bug gets masked because Windows does not care about the case of a directory, whereas Linux does. In any case, it's a bug and as soon as I get a chance to test it, I will be able to verify if it has been fixed.
Btw. It is not a read-only issue, as there's a specific volume with read access to ./bicep/Parameters
defined in run.sh
. See:
...
--volume "${host_deployment_dir}/bicep/Parameters":"${container_deployment_dir}"/bicep/Parameters \
...
many thanks @1iveowl that makes a lot of sense, I also think some sh files were checked-in without execution permissions, particularly in the Saas.Lib, so maybe the documentation should ask to run chmod +x
I was able to recreate the issue, fix it and run a test. It should be working now. https://github.com/Azure/azure-saas/commit/9dd13516ca09c6e25c8be128118e748e81e17ee3
Also fixed the naming inconsistencies and chmod issues.
Please let me know if it works for you now too. Please be aware that you'll have to run setup.sh
again before running run.sh
.
Thanks for reporting this!
Following the instructions of the Identitity Framework, I was able to complete a successful deployment.
Running ./setup.sh from src/Saas.Identity/Saas.Permissions/deployment completes succesfully.
But when attempting to
./run.sh
from the previous folder, I get an error: