Deploying dotnet 7 container with provided dockerfile and resource group not working because of path issue

[PedroCosta93]

So I'm trying to automate the deployment of a dotnet 7 web app and I'm having some troubles. I have the following snippet in my workflow file:

 deploy:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    needs: [build]

    steps:
    - name: Log in to Azure
      uses: azure/login@v1
      with:
        creds: '{"clientId":"${{ secrets.CLIENT_ID }}","clientSecret":"${{ secrets.CLIENT_SECRET }}","subscriptionId":"xxxxx","tenantId":"${{ secrets.AZURE_TENANT_ID }}"}'

    - name: Build and deploy Container App
      uses: azure/container-apps-deploy-action@v1
      with:
        appSourcePath: ${{ github.workspace }}/be/AMP-Program
        dockerfilePath: AMP.API
        acrName: xxxx
        containerAppName: xxxxx
        resourceGroup: xxxxxxx
        runtimeStack: 'dotnetcore:7.0'

So ${{ github.workspace }}/be/AMP-Program is gonna be the path to the solution and AMP.API is the path to the project (where the docker file is).

No matter what i try, there is always some problem with the paths.

This is the docker build logs:

Run docker build \
  docker build \
    --tag xxxx.azurecr.io/github-action/container-app:4630765253.1 \
    --file /home/runner/work/internal-chocolatehorse-monorepo/internal-chocolatehorse-monorepo/be/AMP-Program/AMP.API \
    /home/runner/work/internal-chocolatehorse-monorepo/internal-chocolatehorse-monorepo/be/AMP-Program
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    AZURE_HTTP_USER_AGENT: 
    AZUREPS_HOST_ENVIRONMENT: 
    CA_GH_ACTION_START_MILLISECONDS: [168](https://github.com/valtech-b2b-commerce/internal-chocolatehorse-monorepo/actions/runs/4630765253/jobs/8192830345#step:3:180)0796956801
    CA_GH_ACTION_RESULT_ARG: --property 'result=failed'
    CA_GH_ACTION_ACR_ACCESS_TOKEN: ***
    CA_GH_ACTION_DOCKERFILE_PATH: /home/runner/work/internal-chocolatehorse-monorepo/internal-chocolatehorse-monorepo/be/AMP-Program/AMP.API
    CA_GH_ACTION_IMAGE_TO_BUILD: xxxx.azurecr.io/github-action/container-app:4630765253.1
    CA_GH_ACTION_IMAGE_TO_DEPLOY: xxxxx.azurecr.io/github-action/container-app:4630765253.1
    CA_GH_ACTION_RESOURCE_GROUP: xxxxx
    CA_GH_ACTION_RESOURCE_EXISTS: true
    CA_GH_ACTION_CONTAINER_APP_ENVIRONMENT: xxxxxxx
    CA_GH_ACTION_RUNTIME_STACK: dotnetcore:7.0
    CA_GH_ACTION_INGRESS_ENABLED: true
    CA_GH_ACTION_INGRESS_ARG: --ingress external

After this i have this error: unable to prepare context: path "/home/runner/work/internal-chocolatehorse-monorepo/internal-chocolatehorse-monorepo/be/AMP-Program" not found

And after that: Error: Process completed with exit code 1.

First of all, the internal-chocolatehorse-monorepo/internal-chocolatehorse-monorepo part makes no sense, but that's coming from the github variables so I would say it is ok (My repo doesn't have any duplicate directories). But then, how is the rest of the path not found ? It's literally the path to the solution inside the repo. It's also worth mentioning that I can build the dockerfile locally.

Anyone had this issue ?

[cormacpayne]

@PedroCosta93 Hey there, apologies for the delayed response and that you're running into this issue.

First of all, the internal-chocolatehorse-monorepo/internal-chocolatehorse-monorepo part makes no sense, but that's coming from the github variables so I would say it is ok (My repo doesn't have any duplicate directories).

This seems to be the expected behavior from GitHub when using the GITHUB_WORKSPACE environment via ${{ github.workspace }}. From their documentation:

The default working directory on the runner for steps, and the default location of your repository when using the checkout action. For example, /home/runner/work/my-repo-name/my-repo-name.

This would explain the duplicate repository name you're seeing with internal-chocolatehorse-monorepo.

But then, how is the rest of the path not found ? It's literally the path to the solution inside the repo. It's also worth mentioning that I can build the dockerfile locally.

Just to confirm: does your workflow have a step that clones down your repository using the actions/checkout GitHub Action? This would be the only reason that the context you provided for appSourcePath wouldn't exist on the runner.

One other thing that I would note: the dockerfilePath argument is going to be the relative path to the Dockerfile within the appSourcePath argument, and includes the name of the Dockerfile too, so you may need to update that value to be AMP.API/Dockerfile if Dockerfile is the name of the file and it exists in the /be/AMP-Program/AMP.API folder.

Please feel free to let me know if you have any additional questions!

[cormacpayne]

@PedroCosta93 Hey there, I'm going to close this issue as there doesn't seem to be any additional action necessary from our side, but please feel free to let me know otherwise and I'd be happy to continue a discussion in the comments and/or re-open the issue if necessary. Thanks!