https://garden.io logo
Join Discord
Powered by
Here's a draft of the release notes for Bonsai: h...
# 💻｜contributing
s
Here's a draft of the release notes for Bonsai: https://gist.github.com/thsig/acef9c657166ed82d048db55a796f590 We're missing a summary of breaking changes from here. Could @curved-intern-91221 or @calm-family-29323 write up a rough list of those? I can take care of finalising the language. What do you all think about the high-level structure here? Do we want less/more detail on anything, and are we missing anything in particular?
c
b
Great stuff @swift-garage-61180 ! Regarding the example at the bottom, aren't we missing a 
Test
for 
vote-integ
of type 
container
and similarly a 
Test
for 
vote-unit
of type 
kubernetes-exec
?
Also, should the title be "Garden Bonsai (0.13)" as opposed to "Garden O.13 (Bonsai)"?
s
Haha thanks! > Regarding the example at the bottom, aren't we missing a Test for 
vote-integ
of type container and similarly a Test for vote-unit of type 
kubernetes-exec
? Yeah, good point—it makes sense to have both flavours (
kubernetes-pod
and 
kubernetes-exec
) in there. I need to make a few updates to the 
vote-helm
project anyway, will do this at the same time (and update the snippets accordingly).
I do want to avoid the snippets growing too long, but I can always 
...
some of the lines out.
b
Yeah I get that. But I figured it could confuse users otherwise. Also, if it's too much config "IRL", maybe that's something we need to address on our end.
s
I do think this could be a great use-case for templates (e.g. generating both types of action with a given set of input params).
b
Also, we might want to list how common workflows change. The recommend way to start Garden today is 
garden deploy --dev
which no longer applies. Are there others you can think of?
s
Sometimes, actions feel more verbose. They're also more intuitive and obvious. But templates are a good way to cut down the repetition.
b
Yeah that's true. Although that feels needlessly complex for such a common use case (imo).
s
garden deploy --dev
should still work, since it's an alias for 
--sync
(I noticed this morning that the 
--dev
alias isn't working, will look into that).
b
Ah ok, that might be it. Just ran it on my end and the command just exited.
s
When I tried it, it went through a "vanilla" deploy (i.e. as if no `--dev`/`--sync` option had been passed).
b
Tried 
garden deploy --dev *
and got:
Copy code
✖ Could not find one or more Deploy actions: README.md, policy, project.garden.yml, setupCloud.sh, stackhawk.yml, users.txt and workflows.garden.yml
garden deploy --dev="*"
exists the same way as 
garden deploy --dev
s
> Yeah that's true. Although that feels needlessly complex for such a common use case (imo). I think it might make sense for us to simply ship some of these templates with Garden. Like library functions, where users have access to the same lego blocks to build their own templates.
b
On that topic though, might want to include a section on syncs and the fact that they remain active.
s
Ah, in the Cloud project this might cause problems for a different reason—IIRC we're checking for the 
--dev
option specifically in certain template strings, which we're not doing for the 
--sync
option.
b
> I think it might make sense for us to simply ship some of these templates with Garden. Like library functions, where users have access to the same lego blocks to build their own templates.
Or just 
garden test foo --exec
😉
s
> On that topic though, might want to include a section on syncs and the fact that they remain active. Yeah, true that.
Haha yeah, would be nice. We could come up with a decent primitive around that.
(trying out the reply feature there)
Discord feels nice and lightweight in comparison to Slack.
b
IMO this is one of the things you want to decide at "runtime", as opposed to configuring before hand. In particular since different people on a given team will have different preferences here.
s
@alert-helicopter-61082 had some thoughts on this the other day—I'd be interested in revisiting all this in the coming weeks. The actual functionality should be there, but we can always iterate on the UX around it.
b
Yeah exactly.
a
Phew, there are a lot of topics in this thread
s
In Bonsai, we've got this new 
mode
concept for actions. It's the new way for e.g. Deploy configs to figure out whether they're in sync mode (which is a welcome relief from the rather monstrous template string formula we've been recommending to people for that in 0.12). I'm not sure, but I think it might make sense for the 
kubernetes-pod
Test & Run actions to have an optional 
exec: boolean
field that makes the action instead use the 
kubernetes-exec
mode (using the 
mode
field for the action would be a natural fit there).
Haha yeah
> dudes just back from vacation vibes
a
Can't say I'm grasping what "this" exactly refers to
s
I'm referring to something like whether the above would be a good idea or not. Or whether we should stick to the exec and pod versions of a given Test/Run always being separate configs.
... not a discussion we need to get into right now, btw
The release notes (and the blog post that's based on that) are the main topic here.
a
Okok. Well we should definitely not make a last minute change here, but I'm also fairly firm in that the two styles should be separate. Introducing ever more "modes" to more different action types seems confusing to me.
s
No last-minute changes here, for sure!
5 Views
PreviousNext
Powered by