We'll give you more info and choices if you're trying to deploy
something that would depend on k8s secrets you have haven't configured
yet.
Basically when we would use a secret we'll check k8s first, and then
if it's not found:
- Prompt for it
- Create it if you told us what to put there
- Otherwise print to the commandline the command you could use to
create it.
- We need to bump up the min threads to something reasonable so that the dashboard doesn't take forever
to serve requests. All console IO is blocking in .NET so capturing stdoutput and stderror results in blocking thread pool thread
The thread pool handles bursts poorly and HTTP requests end up getting stuck behind spinning up docker containers and processes.
* Implement single-phase docker workflow
This implements support for building docker images using a single-phase
workflow (publish then build docker). This is going to be faster in
almost every case since it avoids the slowest part of deployment
(running restore inside a container in the multi-phase process).
This additionally supports .NET constructs like p2ps and shared files
without any customization - you can just customize dotnet publish
and be done!
So, switching to single-phase by default because there are few drawbacks
for our target use cases.
* Just for you James!
This implements support for building docker images using a single-phase
workflow (publish then build docker). This is going to be faster in
almost every case since it avoids the slowest part of deployment
(running restore inside a container in the multi-phase process).
This additionally supports .NET constructs like p2ps and shared files
without any customization - you can just customize dotnet publish
and be done!
So, switching to single-phase by default because there are few drawbacks
for our target use cases.
- With 3.1.102 I need to list pipelines explicitly
- Copy test assets to a temp directory (arcade needs it)
- Use .dll on *nix instead of the executable. I'm not seeing the
the executable created on macos. Older versions of tye successful
use the .dll.
This isn't optimal, but right now it's easy to get into problems using
tye because we don't generate manifests with digests.
As an example, if you don't have any versioning in your project, right
now we will *just* tag everything with 1.0.0. This can lead to pods
getting deployed with stale images, even though you pushed!
A better solution is for us to use digests instead of tags.
- Separate 'Hosting.Model' from the YAML processing
- Introduce 'Config*' classes as YAML DTOs
- Refactor 'Hosting.Model' classes to be nullable-friendly
- Fix nullable warnings in M8s.Hosting
- Add support for registry from config
- Add application name to config
- Fix a bug with the wrong file-location used for tye.yaml
- Fix a bug with `tye deploy` at solution scope