It turns out we were deploying twice!
We were deploying each service independently, and then deploying
everything in a batch afterwards (noop).
I chose to get rid of the per-service version because:
- it's less chatty this way
- it's more similar to generate where we produce one file
- we're about to add non-per-service things (ingress)
* 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
This is new command that can be used to delete everything running in a
cluster related to an application using the labels we use.
This currently uses a hardcoded set of resource types. It would be
possible to make this generic, which might become needed in the future.
See comments in the code.
---
The overall design for how to use the command:
```sh
tye undeploy
```
Will read a solution or tye.yaml to get the application name. It then
enumerates and deletes all resources in the cluster with
`app.kubernetes.io/part-of=application-name` (in the current namespace).
```sh
tye undeploy --what-if
```
Will do the same, but without actually doing the deletion.
```sh
tye undeploy -i
```
Will interactively give you a yes/no choice for whether to delete each
resource.
Fixes: #362
This change splits up our evaluation code-path into a few steps:
- Load project
- Do a restore
- Mark dirty
- Run targets and read properties
The key is that we need to do a restore separately from other targets
because restore will bring in nuget packages that contain targets. You
need to let MSBuild load those before continuing. The code here is
pretty similar to what dotnet does.
Additionally blocking the NBGV scenario, there are some additional
assemblies that need to be provided by MSBuild. NBGV also loads
Microsoft.DotNet.Platform.Abstractions which is part of the SDK. Since
we had an allow-list of just nuget assemblies that wasn't resolved.
Fixes#296
Adds conditional logic for passing these properties to `daprd`.
Corrects logic for dealing with config. Dapr's config annotation in k8s
refers to kubernetes resource by name, but that's not possible with
local run. In local run `dapr` will expect the `-config` parameter to be
a file on disk. So, this change adds logic to look for a file by naming
convention and pass that locally instead.
Additionally added the ability for an extension to output to the console
- this is needed because we want to tell the user if their config file
can't be found, and specifically where we looked. I made the decision to
log a message and skip if the config file isn't present, because we
don't have a way to make settings conditional based on environment yet -
it makes sense that someone might need to have a config in production
but not in local dev.
Justin Kotalik
Ryan Nowak
dotnet-maestro[bot]
David Fowler
dotnet-maestro[bot]
Brendan Burns
Igr Alexánder Fernández Saúco
Thang Chung