tsai/tye - tye - Gitea: Git with a cup of tea

788 Commits

30 Branches

11 Tags

20 MiB

Branch: main-publicPoolNames

Commit Graph

Author	SHA1	Message	Date
TeBeCo	1708767426	Handling Multiple TargetFrameworks through BuildProperties (#567 ) * adding a sample project with plural form of TargetFrameworks for debugging purpose * add --framework argument to RunCommand * Pass down "framework" as a BuildProperty if not already defined in the YAML * Do no throw anymore when multiple TargetFrameworks are found, if one was specified as a BuildProperty * replicating Signature change on code base (that does not look like a good idea) * adding comment to be explicit on what this does * Check that the specified BuildProperties["TargetFramework"] is on of the TargetFrameworks * add launchSettings for debug * Create a BuildCommandArguments for the BuildCommand / add a "framework" options to it and move some logic to the CommandHandler (just like the RunCommand) * add "-f {framework}" to dotnet publish if a TargetFramework BuildProperties exists * Create a GenerateCommandArguments for the GenerateCommand / add a "framework" options to it and move some logic to the CommandHandler * Create a PushCommandArguments for the PushCommand / add a "framework" options to it and move some logic to the CommandHandler * Create a UndeployCommandArguments for the UndeployCommand / add a "framework" options to it and move some logic to the CommandHandler * Create a DeployCommandArguments for the DeployCommand / add a "framework" options to it and move some logic to the CommandHandler * framework is now an optional parameter defaulted to null Co-authored-by: Justin Kotalik <jukotali@microsoft.com> * Change sample to use LTS only * Make "framework" argument nullable / optional / defaulted to null * remove "Force" from "PushCommand" and "PushCommandArguments" if it's not used * re-use the equivalent message than "dotnet run" on a project with multiple TargetFrameworks * Create a StandardOptions for Framework * Remove unused StandardOption.Force and add StandardOption.CreateForce with customizable "description" * Use StandardOptions.Framework in various commands * use StandardOptions.Force ni various commands * Create a new InitCommandArguments and re-use the same OutputContext like the other Commands * prefer type alias (String.IsNullOrEmpty => string.IsNullOrEmpty), not sure if it was intended * Adding assets for E2E about multi-targetframeworks that returns the current TargetFramework on every HttpRequest * Adding test for "tye run" with either buildProperties in the yaml or framework passed directly to ApplicationFactory.CreateAsync * Add test and testasset project for both TargetFrameworks and TargetFramework * Always overwrite the TargetFramework if one is specified from the CLI (like dotnet CLi) even if it means it wont build / run etc .... * Test the ability to override TargetFramework from CLI even if define in csproj or in yaml * Consistency over ApplicationFactory.CreateAsync in all E2E tests * rename testasset project to multi-targetframeworks to match generated Dockerfile * Add E2E for tye build when project uses multi-targetframeworks * Adding test directly for ApplicationFactory to check that it overrides YAML existing buildProperties * Adding test to make sure it still throw if there's no explicit TargetFramework or that it is one of the predefined one * Adding test for ApplicationFactory.CreateAsync with a framework if nothing is set in yaml * make cli arguments class private * review: remove extra line * review: remove 'framework' notion from Undeploy * Fix project evaluation of multi-targetd projects * Fixup a few more tests * Comment updates * Ensure TFM is only applied for multi-targeting projects Co-authored-by: Justin Kotalik <jukotali@microsoft.com> Co-authored-by: John Luo <johluo@microsoft.com>	6 years ago

Author

SHA1

Message

Date

TeBeCo

1708767426

Handling Multiple TargetFrameworks through BuildProperties (#567 )

* adding a sample project with plural form of TargetFrameworks for debugging purpose

* add --framework argument to RunCommand

* Pass down "framework" as a BuildProperty if not already defined in the YAML

* Do no throw anymore when multiple TargetFrameworks are found, if one was specified as a BuildProperty

* replicating Signature change on code base (that does not look like a good idea)

* adding comment to be explicit on what this does

* Check that the specified BuildProperties["TargetFramework"] is on of the TargetFrameworks

* add launchSettings for debug

* Create a BuildCommandArguments for the BuildCommand / add a "framework" options to it and move some logic to the CommandHandler (just like the RunCommand)

* add "-f {framework}" to dotnet publish if a TargetFramework BuildProperties exists

* Create a GenerateCommandArguments for the GenerateCommand / add a "framework" options to it and move some logic to the CommandHandler

* Create a PushCommandArguments for the PushCommand / add a "framework" options to it and move some logic to the CommandHandler

* Create a UndeployCommandArguments for the UndeployCommand / add a "framework" options to it and move some logic to the CommandHandler

* Create a DeployCommandArguments for the DeployCommand / add a "framework" options to it and move some logic to the CommandHandler

* framework is now an optional parameter defaulted to null

Co-authored-by: Justin Kotalik <jukotali@microsoft.com>

* Change sample to use LTS only

* Make "framework" argument nullable / optional / defaulted to null

* remove "Force" from "PushCommand" and "PushCommandArguments" if it's not used

* re-use the equivalent message than "dotnet run" on a project with multiple TargetFrameworks

* Create a StandardOptions for Framework

* Remove unused StandardOption.Force and add StandardOption.CreateForce with customizable "description"

* Use StandardOptions.Framework in various commands

* use StandardOptions.Force ni various commands

* Create a new InitCommandArguments and re-use the same OutputContext like the other Commands

* prefer type alias (String.IsNullOrEmpty => string.IsNullOrEmpty), not sure if it was intended

* Adding assets for E2E about multi-targetframeworks that returns the current TargetFramework on every HttpRequest

* Adding test for "tye run" with either buildProperties in the yaml or framework passed directly to ApplicationFactory.CreateAsync

* Add test and testasset project for both TargetFrameworks and TargetFramework

* Always overwrite the TargetFramework if one is specified from the CLI (like dotnet CLi) even if it means it wont build / run etc ....

* Test the ability to override TargetFramework from CLI even if define in csproj or in yaml

* Consistency over ApplicationFactory.CreateAsync in all E2E tests

* rename testasset project to multi-targetframeworks to match generated Dockerfile

* Add E2E for tye build when project uses multi-targetframeworks

* Adding test directly for ApplicationFactory to check that it overrides YAML existing buildProperties

* Adding test to make sure it still throw if there's no explicit TargetFramework or that it is one of the predefined one

* Adding test for ApplicationFactory.CreateAsync with a framework if nothing is set in yaml

* make cli arguments class private

* review: remove extra line

* review: remove 'framework' notion from Undeploy

* Fix project evaluation of multi-targetd projects

* Fixup a few more tests

* Comment updates

* Ensure TFM is only applied for multi-targeting projects

Co-authored-by: Justin Kotalik <jukotali@microsoft.com>
Co-authored-by: John Luo <johluo@microsoft.com>

6 years ago

1 Commits (main-publicPoolNames)