Unable to succesfully complete run.sh for SaaS Administration Service API about azure-saas HOT 17 CLOSED

@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'.

from azure-saas.

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.

from azure-saas.

yes, I'm running from my own forked repo

from azure-saas.

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?

from azure-saas.

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.

from azure-saas.

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.

from azure-saas.

I've looked at this and there was some inconsistencies in the naming that have now been fixed: 4d793ef.

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 \
...

from azure-saas.

I was able to recreate the issue, fix it and run a test. It should be working now. 9dd1351

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!

from azure-saas.

Thank you @alvaradojl for reporting this.

Did you run the setup.sh script first before running run.sh? If so, what was the output?

from azure-saas.

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.

from azure-saas.

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

from azure-saas.

It does, have you managed to reproduce it?

from azure-saas.

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?

from azure-saas.

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

from azure-saas.

@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....

from azure-saas.

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?

from azure-saas.

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 in case they find the deployment container fails with "missing permissions". One more thing, would it make sense to also change the "Parameters" directory to lowercase?

from azure-saas.