* 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>
* Add buildArgs to service configuration and capture build configuration as global property to setup msbuild project
* Fix format
* Fix - Error CS8600: Converting null literal or possible null value to non-nullable type.
* Improve configuration format for build arguments
* Fix whitespace format
* Fix error CS8618: Non-nullable property 'Properties' is uninitialized. Consider declaring the property as nullable.
* Fix error CS8601: Possible null reference assignment.
* Translate non first class properties as /p:{Key}={Value} into the build command
* Fix property translation
* All properties are used to create the msbuild project
* Change the name (to BuildProperties) and the type (to List<BuildProperty>) of ConfigService property to load build properties
* Add support of build properties when tye run with --docker option
* Fix ComprehensionalTest
* Add tests to verify the output directory for the corresponding build configuration
* Fix whitespace format
* Override the correct CreateTestCasesForTheory to fix error CS0618
* Remove the usage of BuildPropertiesToOptionsMap and fix the code format
* Added container proxy for talking to the host
- This change introduces a container proxy which makes it possible for docker containers can talk to host services using container networking. These proxies will not show up in the dashboard as they are "infrastructure" containers.
- Added Private and NetworkAlias to DockerRunInfo but did not expose these configuration.
- All container communication is done using host names.
- Fix host shutdown again
- Bind to all interfaces on linux
* Add configuration option to enable the containers usage of an existing network
* Use IsNullOrEmpty instead IsNullOrWhiteSpace to check the value of Application.Network
* Add tests for network assignment
* Remove network-test assent and use frontend-backend for network tests
* Improve logs in DockerRunner
* Fix whitespaces
* Fix whitespace formatting
* Fix format with dotnet format
* Add assertions to make sure the app working on network tests
* Add test for container -> host communication.
* Small tweaks
- Modify frontend-backend app to print backend url
- Fix log in docker runner
- Rename test to use docker instead of container
* More clean up
- Don't set container port if the service isn't a container
* Bind to all interfaces on linux only
This removes the need to copy-paste code that reads a specific directory
in Program.cs.
Updated docs/samples and tests.
We need a workaround in tests to be able to use a P2P for the library. What
I did here is the same trick we do in Razor.
- Force everyone to use an MSBuild variable to locate the library
- Set that variable in a Directory.Build.props for the normal build
- Drop a special Directory.Build.props for testing
Updates a bunch of test code to use new helper methods for copying
stuff, so we can correctly do this.
* Add support for container networking
- This adds all containers in the tye.yaml to the same container network.
- Container networking only works with a single replica today since the containers are named after their replicas.
- Use the container host name and port when injecting env variables. This handles the replica case by falling back to the host ip and port.
- This cleans up container to container communication when migrating docker-compose files.
- Don't override assign container port if already set.
- Remove StopAsync from TyeHost and exposed DisposeAsync. This patterns removes common clean up and hanging issues that occur.
- Cleaned up run tests to use similar code to run, clean up and capture logs.
* Move where we handle errors while shutting down the host
* Fixed project -> container networking issue
- Only use service name as the host name if both target and source re containers
* Formatting...
* Add service definition to the logs
* Added env variables to disable console colors for process run
* Hit the backend before the frontend
* Small cleanup
- Update docs to use host name for redis cli
- Show docker network and network alias in the API
Fixes: #189Fixes: #153
This change rejiggers the docker build infrastructure to publish the project
and generate a Dockerfile in the same directory. This way they can't be on
separate drives!
Also added some focused tests for single-phase docker build.
Merged the data model we use for m8s features with the features
that come from rynowak/opulence. The `ApplicationBuilder` type (and related
types) now capture all of the details we use for everything.
There's a lot of just moving stuff around in this change - the goal
is to have a separate data model for:
- The config we read
- The representation we mutate
- The data model used by Tye.Hosting
So in this PR there's a lot of righthand/lefthand.
* Add support for running local containers
- This support builds the application locally then volume mounts the application into the container when the --docker flag is specified. Added support for volume mounts and working directory to the DockerRunner.
- Add simple test for tye run --docker
Phillip Hoff
dotnet-maestro[bot]
Tom Deseyn
Justin Kotalik
Hossam Barakat
John Luo
TeBeCo
areller
Shayne Boyer
David Fowler
Ryan Nowak
Igr Alexánder Fernández Saúco
SimonCropp
Justin Kotalik