Add options for pre-commands and environment variables to lambda package command

[mark-hopper]

Describe the feature

Add an option which will allow you to specify a set of commands to be pre-pended prior to the dotnet publish command when using package. Additionally it would be really useful to be able to specify additional environment variables sent to the docker container that is ran.

Use Case

When using a private NuGet feed, we need to make use of appropriate PAT tokens or credentials. In our specific use case we'd like to use the Azure Artifacts Credential Provider, but this requires some installation and setup prior to the dotnet publish command.

In the case of the installation, I'm aware we can go ahead take the base image, add what additional tools we need, and then use the -cifb switch to specify the appropriate container. But this is only part of the problem, in order to use the credentials provider we need to specify additional environment variables namely VSS_NUGET_EXTERNAL_FEED_ENDPOINTS which currently as far as I can see the CLI does not support us providing as part of the build.

For context the above is in reference to a .NET 8 AOT Native build.

The only workaround that I can see currently, is to specify the credentials in plaintext in the Nuget.Config file at the root of the project prior to running the dotnet lambda package command, which is not ideal.

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

Targeted .NET platform

8.0.303

CLI extension version

5.10.7

Environment details (OS name and version, etc.)

MacOS Sonoma 14.5

[bhoradc]

This needs to be reviewed with the team.

[normj]

Hi @mark-hopper, why wouldn't you set the VSS_NUGET_EXTERNAL_FEED_ENDPOINTS environment variable yourself before executing the the dotnet lambda command. Or is this to get the container environment that dotnet lambda is spinning up for AOT to have this set?

[mark-hopper]

@normj this is for the latter case in your question, there is no means to set additional environment variables against the container, nor install the required tools I need prior to running the dotnet lambda package command

[normj]

That makes sense, so should it be a switch to specify script file that runs once the container is started? I would rather not have this tool be the one to figure out how to run the commands because I can imagine users coming up with complicated scenarios that shell scripts already solve.

[mark-hopper]

@normj I can see your concerns, and would agree if you add a switch to specify a scripting file, it's then on the consumer of the command to manage the script