* 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
Fixes: #206
This change only applies to the logic that we use to look at solution
files. This adds a heuristic that we only include projects with a
launchSettings.json for these operations (when considering a solution).
This will exclude unit test projects and class libraries.
In this case where the user has a `tye.yaml` then whatever's in there
will win. Likewise if a user passes a path to a project directly then
we'll try to run it without asking questions.
I chose `launchSettings.json` for this because it's a decision we can
make really quickly without having to run any MSBuild code. When we
think about operating on a solution with 50 projects with `tye run` we
really really don't want to have to evaluate each project with MSBuild
to figure out what kind of project it is (500ms).
Implements two flavor of library support for service-discovery:
- GetConnectionString (arbitrary strings) augmenting existing
functionality already in asp.net core
- GetServiceUri (uris) can be combined
from a protocol/host/port triple
See the **extensive** doc `service_discovery.md` that is filled out in this PR. That documents pretty much everything about how this works now.
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 Dapr integration to Tye
Adds a new `extensions` integration point. Currently all extensbility has
to be inside the Tye codebase. There's no functionality for loading or distributing
plugins.
Enable dapr for an application like:
```yaml
name: test_app
extensions:
- name: dapr
```
The dapr extension currently accepts and requires no additional options, and applies
to all services defined in the application.
What it does:
- In local run: starts a dapr sidecar for each project that does http
- In local run: sidecars start in the directory of tye.yaml, so dapr will look for
component manifests in ./components (relative to tye.yaml
- In deployment: adds required annotations to deployments
Some new features that were added to tye to enable this:
- Config: Ability to parse and conditionally run extensions
- Run: Ability to token replace env-vars into command line args
- Deploy: Ability to configure labels and annotations
* format
* Massage labesl:
* PR feedback
* Fix tests
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.