[Issue] Allow service to be in "services" (azure.yaml), but not participate in some commands like deploy

[jongio]

I have two services:

Frontend

Backend

I want to be able to call restore on the Frontend locally, and I therefore need it listed in the "services" section of azure.yaml

BUT

I do not want azd to deploy that service.

Could we add a flag, something like "skip-{command}" to azure.yaml so I can restore it using restore, but not deploy it when deploy is called.

[vhvb1989]

restore and deploy have support for --service argument. You can use that arg to opt-in what service to restore/deploy

If we want to support opt-out, what about adding an exclude arg ? instead of updating the azure.yaml ?

[jongio]

I want to be able to call the azd commands naked because not deploying a service is how the app works and is the norm for the app. I don't want to have to use a service flag because I would have to use that every time I call a command.

[Petermarcu]

I was wondering if we should have another type of app that isn't service for this scenario? The same would be true if I had a desktop or mobile app that is part of my solution. Should we consider "client" alongside "service" and clients never deploy?

[vhvb1989]

The same would be true if I had a desktop or mobile app that is part of my solution

I'd be curious to know what would it be the motivation of using azd for a non-Azure service. Like, for a project which is neither using /infra (bicep/arm/terra/etc) and neither deploying code to an existing IaaS (web apps, container, etc).

One use case, I guess, could be to have one single command at the root of my entire solution azd build which take care of all my projects, regardless of what type of project it is... but this is not scalable. It looks attractive at first, but as soon as there are more and more projects, the time to build them all is a concern. Take, for example, .Net or Java SDK repos. One can imagine a root command on the top to build all sdk clients within the repo... but, in reality, they would take a long long time, as the projects might be related, but not necessarily required to be built all together...

[rajeshkamal5050]

Some of them could be,

• May be building cli's, thick clients, custom scripts/automation hosted and served in-house consuming Azure Services, or apps built on azure.
• May be they want some aspects of app always to be hosted in house.
• May be they are migrating and moving some aspects of the app.

[weikanglim]

• If we made azd deploy <service> and azd restore <service> always accept a service, then it wouldn't trigger deploying of random services you don't want by simply running command. We can make the default (without service) work if there's only one service defined in azure.yaml.
• If we made azd up a configurable orchestration, you as a template owner or an application owner, can define what azd up does for your service(s) -- which doesn't involve restoring, deploying, or anything that you don't want for a service.

Commands should be single purposed. However, given the coverage of azd in inner-loop scenarios, there are places where we do need to allow --skip-<x> where it makes sense.

I also don't think azd services should be defined in azure.yaml for libraries, or apps that are not deployed to Azure. There are build orchestration tools (make, msbuild, npm, etc) that solves that problem.

[johanste]

My concrete example was to install (restore) dependencies of a client-only script that processes and uploads data. The dependencies are not needed by any of the deployed services.

Azure-Samples/azure-search-openai-demo#11