search

dotnet / tye

Tye is a tool that makes developing, testing, and deploying microservices and distributed applications easier. Project Tye includes a local orchestrator to make developing microservices easier and the ability to deploy microservices to Kubernetes with minimal configuration.
MIT License
5.29k stars 520 forks source link

Allow service to be passed as argument for tye run --watch (like --debug) #1567

Open razvangoga opened 1 year ago

razvangoga commented 1 year ago

What should we add or change to make your life better?

Because i'm generally interested in watching one or two of my dotnet services not all of them. To align cli behaviour between --watch and --debug

Why is this important to you?

See above

philliphoff commented 1 year ago

Given that moving to --watch <services> would be a breaking change (e.g. for existing scripts, the VS Code extension, etc.), I'm not sure there's an overriding benefit. Whereas --debug <services> has real impact to the user (as the startup behavior differs/halts based on the setting), --watch should mostly be invisible to the user (until a change is made) whether one service is watched or all.

Is there a specific reason why a user might not want a specific service being watched or where it might be problematic? If so, I wonder whether it might make sense to either (1) try to make the behavior backward compatible (e.g. --watch be equivalent to --watch *) or (2) use a different argument (e.g. --watch means all services, while --watchServices <services> allows the user to be explicit).

razvangoga commented 1 year ago

As far as i remember (i wrote this point down some 9moths ago -> https://gist.github.com/razvangoga/971767f1fa9c7684edbe2fbcaaa2db8e ) i've had strange issues when running watch on a config with a lot of services (15+ dotnet + others (containers / node)). Running a non watch worked fine. Can't remember if it was on win or on mac (we had guys in the team on both). I guess i could try to repro it.

In any case, i see your point about the backcompat - i would prefer the 1st version where --watch is taken as --watch * instead of just adding a new prm.

philliphoff commented 1 year ago

@razvangoga That's fair. I think I've seen issues, in particular, when multiple services reference the same set of common libraries (i.e. races in the parallel builds kicked off by watch). I'm ok with an explicit means to indicate the services to watch aside from the concern about impact to existing scripts/tooling, and user experience (--watch being easier to remember/type than --watch *). If there's a way to make --watch work the same, then agree that'd be the best option.

razvangoga commented 1 year ago

Yeah, I think that was it - we had a project setup in which a core lib (or a bunch of them) was (were) shared between 3 surface processes (a webapi, a worker service and a cli that would run the EF migrations) - all of them were started via tye.