Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a --profile option to dotnet publish to expose PublishProfiles as first-class concepts. #26161

Open
Tracked by #35552
baronfel opened this issue Jun 22, 2022 · 1 comment
Assignees
Labels
Area-CLI cli-ux Issues and PRs that deal with the UX of the CLI (exit codes, log output, verbs/options, and so on) untriaged Request triage from a team member

Comments

@baronfel
Copy link
Member

baronfel commented Jun 22, 2022

Is your feature request related to a problem? Please describe.

Currently, users can define PublishProfiles for use with dotnet publish. These profiles are XML Project files that contain properties unique to a specific

a) publish mechanism, like a filesystem folder containing all of your assets, or a build of a Dockerfile), and
b) publish target, like the filesystem folder to which to publish, or the external Registry to push the generated Docker image to

The default publish profile is a filesystem publish to the /publish directory, and users are likely already quite familiar with the behavior of this, but there are several others included in the SDK, and various tooling in Visual Studio (and other mechanisms) will scaffold out PublishProfiles on your behalf.

To use a specific publish profile, the user has to add the following MSBuild property: /p:PublishProfile=<Name of profile>. This is obtuse and easy to typo.

Describe the solution you'd like

I propose a new string Option be added to the publish Command - [--profile PUBLISH_PROFILE_NAME]. This command must take a single argument that is the file name (without extension) of a PublishProfile that exists in <project root>/Properties/PublishProfiles OR the name of one of the in-box, default PublishProfiles (which are located here) . The user-provided value will be forwarded to the Publish target as the value of the MSBuild property PublishProfile. Tab-completion for this property can be quickly determined based on these files, but we should probably filter the list by the value of the WebPublishMethod inside the PublishProfile itself - some methods do not work on non-Windows systems.

Example usage

# shows an example invocation
> dotnet publish --profile PushToAzure
# shows how tab completion with no text stem looks
>dotnet publish --profile <TAB>
Default
DefaultMSDeploy
DefaultMSDeployPackage
DefaultZipDeploy
PushToAzure
@dotnet-issue-labeler dotnet-issue-labeler bot added Area-WebSDK untriaged Request triage from a team member labels Jun 22, 2022
@baronfel baronfel added Area-CLI cli-ux Issues and PRs that deal with the UX of the CLI (exit codes, log output, verbs/options, and so on) and removed Area-WebSDK labels Jun 22, 2022
@HughWarrington
Copy link

Can I request that this also fails when you provide a publish profile that doesn't exist? Would fix #28370.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-CLI cli-ux Issues and PRs that deal with the UX of the CLI (exit codes, log output, verbs/options, and so on) untriaged Request triage from a team member
Projects
None yet
Development

No branches or pull requests

4 participants