dotnet eb deploy-environment not setting the Procfile web startup properly

[ddivita]

Describe the bug

I will preface this by saying this could be a GitLab pipeline issue, however, I have also seen this happen on a local development machine.

Command:

dotnet eb deploy-environment --application $EB_APPLICATION_NAME --environment $EB_ENVIRONMENT_NAME --version-label $CI_COMMIT_SHA-$CI_JOB_STARTED_AT --self-contained true --region $AWS_DEFAULT_REGION

GitLab script:

api_deploy_job:
  stage: deploy
  image: mcr.microsoft.com/dotnet/sdk:7.0
  only:
    - develop
  script:
    - echo $CI_COMMIT_SHA
    - echo $AWS_DEFAULT_REGION 
    - apt-get update && apt-get install -y unzip
    - apt-get install -y zip   
    - apt-get update
    - apt-get install -y awscli
    - dotnet --version
    - aws --version
    - dotnet tool install -g Amazon.ElasticBeanstalk.Tools
    - export PATH="$PATH:/root/.dotnet/tools"
    - cd HP.Api         
    - dotnet eb deploy-environment --application $EB_APPLICATION_NAME --environment $EB_ENVIRONMENT_NAME --version-label $CI_COMMIT_SHA-$CI_JOB_STARTED_AT --self-contained true --region $AWS_DEFAULT_REGION

The script initiates the dotnet publish command:

dotnet publish "/builds/hp-services/HP.Api" --output "/builds/hp-services/HP.Api/bin/Release/net7.0/publish" --configuration "Release" --framework "net7.0"  --runtime linux-x64 --self-contained true

After the publish compiles the project and creates the files, the Procfile is auto-generated. The issue is the Procfile is not setting the proper startup web assembly.

Expected Behavior

Running the same command on a local environment produces this Procfile:

Current Behavior

The auto-generated Procfile is pointing to the wrong assembly. It's not always the same assembly either, but it never picks the API assembly. Even when the Procfile is created manually, it still does not deploy properly.

Reproduction Steps

I'm not 100% sure what might be going on, but I have a Minimal API that is also referencing an MS Test project. I'm not sure that is the issue since I can run the commands locally without issue. It could be the docker image used for the deployment.

I have another minimal API project that deploys fine in GitLab and locally. This project has no references to any other projects.

Possible Solution

I tried creating a Procfile that is set to Copy Always in the root of the API project. This does not work locally or in the pipeline.

Contents of the Procfile

web: ./HP.Api

This is in the logs, which makes sense:

However, the instance does not deploy properly:

Additional Information/Context

No response

Targeted .NET platform

.Net 7

CLI extension version

AWS CLI:
aws-cli/1.19.1 Python/3.9.2 Linux/5.4.109+ botocore/1.20.0

Donet EB:
dotnet-eb Tool 'amazon.elasticbeanstalk.tools' (version '4.3.2') was successfully installed

GitLab Runner:

Running with gitlab-runner 16.1.0~beta.59.g83c66823 (83c66823)
  on blue-3.saas-linux-small-amd64.runners-manager.gitlab.com/default zxwgkjAP, system ID: s_d5d3abbdfd0a
  feature flags: FF_USE_IMPROVED_URL_MASKING:true
Preparing the "docker+machine" executor

Using Docker executor with image mcr.microsoft.com/dotnet/sdk:7.0 ...
Pulling docker image mcr.microsoft.com/dotnet/sdk:7.0 ...

Environment details (OS name and version, etc.)

linux

[ashishdhingra]

Hi @ddivita,

Good morning.

Based on initial high level look, I'm not sure if the Procfile is a .NET Core application compilation/publish concept. Based on the below articles, it appears to be Linux concept not specific to .NET:

• Using a Procfile to configure your .NET Core on Linux environment
• Extending Elastic Beanstalk Linux platforms

So just curious on how in your case, the Procfile is auto-generated. Also if you are manually crafting Procfile, you might want to set it to relative path of .NET assembly (e.g. web: dotnet ./dotnet-core-app1/dotnetcoreapp1.dll) as documented in the 1st link above.

Unsure if this is the AWS .NET CLI extensions issue since Procfile creation is probably not handled by our tooling, and its process by ElasticBeanstalk environment.

CC @normj

Thanks,
Ashish

[ddivita]

@ashishdhingra The Procfile is definitely being auto-generated by something ;). I can see the file in the zipped code and looks exactly like the example I set manually.

[ashishdhingra]

@ashishdhingra The Procfile is definitely being auto-generated by something ;). I can see the file in the zipped code and looks example like the example I set manually.

@ddivita Is it generated automatically locally when compiling under Visual Studio? If not, might be there is some step in your pipeline that generates it!

[ashishdhingra]

@ashishdhingra The Procfile is definitely being auto-generated by something ;). I can see the file in the zipped code and looks exactly like the example I set manually.

@ddivita Looks like I found EBUtilities.SetupPackageForLinux() which uses the existing Procfile if found, else creates a new one with web: content here for Linux environment.

Could you please share the sample project for reproduction with folder structure for issue?

Thanks,
Ashish

[ddivita]

@ashishdhingra I think I see what might be going on. That method you posted led me to look at the runtimeconfig.json file. There are several, and that code picks the first file it sees which is why it may have been failing? I wonder if I only have 1 runtimeconfig if it would work properly.

Code:

Files in the .zip

[ddivita]

@ashishdhingra I think I see what might be going on. That method you posted led me to look at the runtimeconfig.json file. There are several, and that code picks the first file it sees which is why it may have been failing? I wonder if I only have 1 runtimeconfig if it would work properly.

Code:

Files in the .zip

This was the issue. I set the <GenerateRuntimeConfigurationFiles>false</GenerateRuntimeConfigurationFiles> for any project I didn't want the runtimeconfig.json to be generated. The deployment worked fine after this.

[ashishdhingra]

@ashishdhingra I think I see what might be going on. That method you posted led me to look at the runtimeconfig.json file. There are several, and that code picks the first file it sees which is why it may have been failing? I wonder if I only have 1 runtimeconfig if it would work properly.
Code:
Files in the .zip

This was the issue. I set the <GenerateRuntimeConfigurationFiles>false</GenerateRuntimeConfigurationFiles> for any project I didn't want the runtimeconfig.json to be generated. The deployment worked fine after this.

@ddivita Thanks for the findings and update. Please confirm if we are good to close this issue.

Thanks,
Ashish