#Preparing Paris Meetup
1 messages Β· Page 1 of 1 (latest)
Quoting @bronze glacier :
Add to shykes:zenith-functions branch:
Alex's services-v2-zenith branch on the dagger fork
Eric's zenith-functions-shell branch on the dagger fork
Jeremy's shykes-dagger-zenith-builder repo (stretch goal?)
cc @sand mason @quaint yarrow @half tendon @polar pendant @eternal onyx
@sand mason @tardy belfry I pushed the fix that broke the hourly build
@sand mason could you confirm that it works on your end? (I'm not sure how but will look into the hourly build repo how to run the exact same query)
Ah there's one query per target platform: https://github.com/jpadams/shykes-dagger-zenith-builder/tree/main/graphql
Note: we should probably pin the version of my module used by this release workflow, to avoid the same problem happening again π
@sand mason I just got admin access from Jeremy (you should have it too), I'm re-running the flow
@sand mason now has access to Fly.io, where daggerverse is running: https://fly.io/apps/daggerverse/monitoring. He will need this to add the module instructions.
To deploy a daggerverse update, AFAIK itβs just a matter of running fly deploy in the dir where this file is: https://github.com/dagger/dagger.io/blob/daggerverse/daggerverse/fly.toml
I donβt think that this will be needed, but to deploy a daggerverse-engine update, AFAIK itβs just a matter of running fly deploy in the dir where this file is: https://github.com/dagger/dagger.io/blob/daggerverse/daggerverse/engine/fly.toml
cc @tawny venture
Quick question for @slim turtle: I am assuming that you will be demoing from macOS running Docker Desktop locally. Asking so that I can use the same baseline as you for double-checking that dagger serve works as intended.
Yes correct
But can't hurt to test on other clients if possible, since others will be using that build too
I'm going for a quick lunch, ping me if you need anything
@sand mason maybe not realistic for today, but just in case: it would be cool if the documentation page for writing a zenith module, were a regular page in our open-source docs, and the daggerverse deployment pipeline somehow cherry-picked it and added it to the daggerverse app. Of course even cooler if this were done via dagger π Just a thought
(I was picturing daggernauts reporting caveats, and volunteering to contribute them to the mod development FAQ, only to realize it's not possible)
@quaint yarrow I think if your netlify / nextjs / vercel modules work, it would be cool to show them at the meetup. It would be great to have a simple and realistic "deploy a webapp" demo
more complex than "hello world", less complex than "ship the entire dagger engine with the dagger engine"
@bronze glacier one cool detail of the "release zenith with zenith" work: the address of the remote worker container is fully parametrized π So you can release a custom CLI build, which will download its worker container from a custom remote registry
Makes it much easier to make test/staging/demo builds that are self-contained
Yes, that would be my suggestion too: add the Zenith module page to docs.dagger.io, perhaps as a hidden page, instead of the daggerverse. This should help: https://github.com/dagger/dagger/blob/main/docs/_README.md
@slim turtle I was thinking about completing the node/go/python module so people can have an example of modules with some useful pattern (for instance embedding a container into a structure to simplify its capabilities)
WDYT?
I can also help to review @sand mason guide
Adding this as a hidden page somewhere in https://github.com/dagger/dagger/tree/main/docs/current would be super helpful. cc @past fossil
Yeah that sounds useful. Do you have something already published, that you will continue?
https://github.com/TomChv/daggerverse/tree/main/node
I want to make it cleaner, and then probablly add golang and python based on the same pattern
I'm open to any suggestions to make the code looks better btw
I'll also add gql queries directly in this module instead of at the root of the repository
@sand mason Something cool to include in your guide is how to import and use an external module / extend it (I could not find the proper pattern to extend it nicely)
Hopefully once the CLI features drop, gql queries will be unnecessary
This would be soooo nice, working with raw GQL embedded in bash script is not cool
I'm gonna start working on the guide asap - I'll start with the existing README, and add from there.
If anyone wants to pitch in, I'll be working on it on hackmd: https://hackmd.io/@jedevc/rJVmBw-ba/edit
OK now I'm really getting a quick lunch π When I'm back I'll join dev-audio or something, if anyone feels like a "war room" atmosphere π
Yes, I'm going to work on it
FYI @bronze glacier , @timber lake is going to try his hand at the daggerverse codebase. The goal is to fix a small ergonomic issue we all experienced during the hackathon. And it's a great excuse to try applying the fast and furious model π
@bronze glacier No worry I'll also take care of OS work today! It's a small task I have to do
Quick note on this: in the hackathon I came across a bug where it's not possible to add a dependency on more than one module at a time. I'm not sure if it's still there (I discussed it with @tawny venture) but would be worth adding as a caveat if so
Happy to work on this with you, please lmk where I should pitch in π
Hi, I'm around π
cool, i've been having this as well π https://discord.com/channels/707636530424053791/1154487219315294290
I would definitely add this to a list of tip & tricks
others that come to mind:
- Private fields will not be persisted
- Public fields require a
json:βfooβtag to be queriable
(quickly gonna grab lunch myself, then will get back to it)
- the context and error return are optional
does dagger mod use work with local paths as well?
I was about to ask the exact same thing
{
"name": "flyio",
"sdk": "go",
"sdkRuntime": "vito/dagger-sdk-go:no-vcs-flag@sha256:0fcc9d2659cdd551acb7aaf25e77215e9687475eb89ec06cae989eaf332ee480",
"dependencies": [
"/Users/slumbering/forks/daggerverse/nextjs-build"
]
}
This doesn't work for me βοΈ
In the hackathon, the workaround was to move the dependent modules into a directory of the parent one, then use the relative path
Oh yea you're right
I've started adding TODOs into the hackmd of places I'd appreciate a hand π anyone is welcome to help out β€οΈ
Public fields require a
json:βfooβtag to be queriable
do you know if this one is intentional, or if we intend to fix that? i added to https://github.com/dagger/dagger/pull/5757#issuecomment-1752775608.
I think it was more of an organic fix
Without that tag, the field names come straight from the standard Go json encoder logic. This results in a Go field Foo becoming a JSON field Foo. This doesn't match the expectations of <insert some other zenith component here> causing things to fail
right I think I discussed with with Erik now π Yeah, this works for now, ideally we find something that feels a bit more natural (though not before tomorrow π’)
thanks β€οΈ
Added some stuff, will continue working on it later today
I think I've got all the main sections now? I don't think there's any critical functionality I'm missing now?
(except for maybe shell, cc @polar pendant how's the rebase going?)
Not sure if relevant but is there anything we should mention re: modules and caching (both for dev/test and usage?)
definitely worth a mention - maybe we should have a "known issues" section, or we can find somewhere to put it inline?
I like "known issues" and I'd also add an internal anchor to it in the troubleshooting section so that it's immediately visible to users who are trying to debug problems
I think I've got something working with both services and shell: https://github.com/grouville/dagger/tree/merge-shell-services-zenith. But, still not finished on the proper rebase
Do we also want to add a section in this doc on "how to make your module discoverable on daggerverse"? I'm not sure if there is a separate place for that, if so then we can link there.
"How to publish your module" -> yes definitely
Done π
note that @timber lake is trying to make a change to the daggerverse ui itself, and if anyone is looking for their next task there is another change on the queue that would be a great stretch goal for tomorrow. Specifically moving the text field + βcrawlβ button at the top of the page, which everyone confuses with a search field, to a separate βpublish a moduleβ page, with a link to that page from the main page
(Tom is working on replacing the list of updates with a list of modules)
I'm about to finish btw! I think I found the correct request to do
@past fossil @sand mason did you figure out where you want to host the new module doc? Do you think we can change the daggerverse app today to link to the new doc?
not worked it out yet no π¦
i'm tempted to just update the README in the zenith-functions branch, and then to work out how to nicely publish that onto the daggerverse site?
i might be a bit pressed for time though
I think decoupling from the dagger/zenith repo trumps other considerations (ideal tooling, esthetics etc). Maybe move it to a gist that we can collaborate on? Then we iterate from there?
I was thinking we could follow Gerhard's suggestion in #1160882513384837120 message
- a static page on docs.dagger.io
- possible URL docs.dagger.io/labs/project-zenith
- visible notes on page: this is experimental, this page is ephemeral
- not linked in sidebar
- sets up a pattern for future experiments as well ie. /labs/xx
alt: we could also link it from the sidebar as a node called "Labs (experimental)", we have precedent already (Elixir SDK docs) but this makes it indexable
WDYT?
Yes I like this. Just wondering if there's a "quick and easy" intermediary step before that, so that we can jettison the dagger repo within the next say, 60mn
if it helps, you could use the same Markdown => HTML bit that exists for module READMEs and apply it to the Zenith README content (which could just be copy-pasta'd or go:embed'd), and just give it its own page + link
I can move the current README @sand mason is working on (already in markdown) to a docs PR quickly and then we can work on it there?
(also it's Canada Thanksgiving today, just hanging around if there are any blockers :P)
OK start the clock
@sand mason snapshotting https://hackmd.io/viBxr-QATcap2_9xUsgejQ now
Sorry @sand mason for mistyping your username π
So, I just edited the PR's context https://github.com/shykes/dagger/pull/125 to include how to play / test with the dagger shell example. Works fine on my side
I'm trying to use a dependency but couldn't figure out how to make it work.
Dependencies:
Usage:
error:
Probably easy to fix, but I couldn't figure it out ... 
agh this is a weird bug i think - if your code won't build, then the generation fails.
i've worked around this by commenting out the guilty looking bits, and then re-running generation, then commenting it in again
Thanks. I've just tried it but the error is still here. It's probably related to the way NextjsBuild is implemented.
I'm going to push a basic CLI to the branch.
Ok, the mistake was .....a typo
. Thanks @sand mason
@sand mason @slim turtle https://github.com/dagger/dagger/pull/5853. Preview at https://deploy-preview-5853--devel-docs-dagger-io.netlify.app/labs/project-zenith/.
Pushed. There's only dagger call list and dagger call [function] (top level, without args and that returns a string) but putting it out there so others can hack on it if you want.
What happens if I call my function list? π
Yeah, that's not final. In the TODO I put --help, or maybe a verb.
@sand mason I've been able to sync my module thanks to the registry π₯³
next step is to deploy on Fly.io π
@polar pendant I'm sorry I didn't see your PR on my fork! Please go ahead and merge at your discretion, you should have permissions since it's a fork. Just make sure it doesn't break everything π
In fact you don't need a PR at all, you can just push to the branch (again, be careful to not break, and communitcate with the other devs on the branch)
I don't have the permissions. And I wanna double check with Justin on this one
Yes I do
Probably. yep, you can close, I'll sync with Justin directly
OK
lgtm to merge - @polar pendant could you also add the note of how to use it to the docs pr that @past fossil opened?
sorry, i'm deep in "what's going on with schema merging hell" so i can try and have the hugo module ready for tomorrow
donβt worry about hugo module, definitely less urgent π
@eternal onyx good news! First successful call of dagger call list π
Some bad news however: it never returns, I have to control-C to get my shell back
Hmmm... which module does this happen? Do you have it published?
% dagger -m ./helloWorld call list
β list functions [0.22s]
β function name description
β with-greeting Change the greeting
β with-name Change the name
β message Say hello to the world!
β shout SHOUT HELLO TO THE WORLD!
β’ Cloud URL: https://dagger.cloud/runs/99cf68bd-d982-4fb1-a795-9e7ee9ab0176
β’ Engine: 7f38078129e2 (version devel ())
β§ 0.61s β 26 β
13
%
Or maybe it's the environment, not the module.
I ran it against my loca copy of helloWorld, but it is an unmodified version of the one that is published
That's the one I tested the cli on
Same issue when running against a remote version
nevermind, it returned. Maybe it's actually a slowness problem rather than a hang problem
% time dagger -m github.com/shykes/daggerverse/helloWorld call list
β list functions [0.34s]
β function name description
β with-greeting Change the greeting
β with-name Change the name
β message Say hello to the world!
β shout SHOUT HELLO TO THE WORLD!
β’ Cloud URL: https://dagger.cloud/runs/3b45ff16-2697-47f4-8830-73d51990f0c0
β’ Engine: 7f38078129e2 (version devel ())
β§ 4.63s β 45 β
14
dagger -m github.com/shykes/daggerverse/helloWorld call list 0.62s user 0.46s system 7% cpu 13.639 total
%
Correct, it always returns. Slower with local version for some reason
% time dagger -m ./helloWorld call list
β list functions [0.31s]
β function name description
β with-greeting Change the greeting
β with-name Change the name
β message Say hello to the world!
β shout SHOUT HELLO TO THE WORLD!
β’ Cloud URL: https://dagger.cloud/runs/4f76cc5b-f909-478e-8424-12c239733b26
β’ Engine: 7f38078129e2 (version devel ())
β§ 1.48s β 26 β
13
dagger -m ./helloWorld call list 0.46s user 0.34s system 7% cpu 10.240 total
Actually it's super weird, because the actual time it took is not 1.48s.. My terminal was stuck for a good 10 seconds
But nevermind it's at the end: 10.240 totaltime doesn't tell me that? Super weird.
% /usr/bin/time -h dagger -m github.com/shykes/daggerverse/helloWorld call list
β list functions [0.29s]
β function name description
β with-greeting Change the greeting
β with-name Change the name
β message Say hello to the world!
β shout SHOUT HELLO TO THE WORLD!
β’ Cloud URL: https://dagger.cloud/runs/e371984f-3dff-4b39-b079-83aa2dca55a4
β’ Engine: 7f38078129e2 (version devel ())
β§ 4.01s β 45 β
14
8.26s real 0.43s user 0.42s sys
Seems related to https://github.com/dagger/dagger/pull/5712. (at least, similar experience of exactly 10s hangs)
@eternal onyx, can I push on the branch ?
Yes
Done, rebased dagger shell. Now still rebasing the services v2 (as a follow-up) π
ok random question - has anyone noticed that when playing with a lot of modules it feels possible to get dagger into an inconsistent state? i ask because, i can sometimes resolve weird module resolution issues just by restarting dagger.
maybe i'm just imagining things π€
I've pushed, and have resolved the TODOs I left - should hopefully be good to go π
π zenith playground is already deployed:
DAGGER_SESSION_TOKEN=daggerverse ./bin/dagger listen --allow-cors --progress=plain
https://zenith.play.dagger.cloud/
^ that should connect to your local engine.
Welcome to Dagger API Playground
take into account that once a module is registered, the only way to de-register it is by restarting the engine since there's no API for that yet.
@grim tide what I would love to see is somehow integrating this into each module page in daggerverse ui
find a module, navigate to its page, boom I can start a playground right there without leaving the page
Also I would love if the playground only showed my moduleβs API, instead of drowning it in the 100 fields and types of the core dagger API
(two very different requests I realize)
just writing my letter to santa π
π ποΈ
@slim turtle can you take a look to see if the docs lgty? if so i should be good to merge and roll out the link change to daggerverse
(otherwise, i can take a look first thing early tomorrow morning)
I think itβs fine to merge assuming it doesnβt break or change the standard docs experience? ie itβs hidden yes?
assuming yes: letβs merge and we can iterate tomorrow (or even tonight if I or someone else finds something to improve)
can someone give an approval on https://github.com/dagger/dagger/pull/5853 - i can't merge without one
done. Also you should be able to approve/merge yourself. As in: weβll fix the fact that you canβt
@slim turtle @tawny venture https://github.com/dagger/dagger.io/pull/2947 updated
is there anything that i need to do to update the docs? the labs page seems to have displayed correctly in the netlify deploy preview, but it's not showing on docs.dagger.io as expected
hm never mind, i've found the deployment in netlify, it's just not got that page for some reason π’
Merges get auto published to devel.docs.dagger.io
Can you check if you see it there?
aha it is there π
i just found the instructions about this, i don't have access to netlify
I can do it. Should I do so now?
π please!
(i've deployed the update to point daggerverse to it now - cc @timber lake @tawny venture)
@sand mason , some minor fixes/additions for review https://github.com/dagger/dagger/pull/5855
dagger.io deployed with Zenith:
https://dagger-io-with-zenith.fly.dev/
@slim turtle do you want to check that this README works for you? https://github.com/vito/daggerverse/tree/main/concourse
Works on my machine:
I cannot see the update when I go to daggerverse.fly.dev
I mean, there are still duplicates, that should not be possible
Ah sorry, I only deployed the commits I just pushed to daggerverse branch, not your PR
So duplicates will still be there I think
Thank you all for your help today !
π did anyone deploy daggerverse.fly.dev?
seems like some commits got removed and the playground stopped working
cc @bronze glacier
Oh no π― that would have been me π
I think I screwed it up, it should just be able to deploy it again from the top of the daggerverse branch
π np. want me to take care of it? I'm aware it's quite late for you
Yeah go for it π (thanks thanks, sorry, I was rushing it towards the end of the day)
np, F&F π
k, fixed π
@sand mason I let you deploy https://github.com/dagger/dagger.io/pull/2947, I'm not in the fly organization so I think you'll be way faster than me to deploy it π
I think I should just be able to add you to the org π€ (just done that, cc @bronze glacier)
Do we have any doc explaining how to deploy using fly?
I saw that comment (https://github.com/dagger/dagger.io/pull/2947#issuecomment-1753477504) but I wonder if we have some steps written somewhere
afaik, no - i did it with fly deploy in daggerverse directory.
Ok, new version deployed
pretty awesome, seems to be trying to hit my localhost:8080 though, not sure if that's intentional
@grim tide @plain oasis playground link is obviously very cool BUT we need a way to embed each individual playground inside its corresponding module page inside the daggerverse UI. Linking out to a separate playground app, with its own catalog of modules, is too much complexity for the user
Agree, I'll try it out, maybe I can have a working version before the day ends there
Good luck today everyone! Can't wait to see pictures π
do you mean the playground or daggerverse?
the playground should POST to localhost to use the local engine to execute the queries as the engine in prod doesn't support modules yet
ah ok, yeah I meant Playground, didn't know that was by design, makes sense! maybe a call-to-action to start a local dagger listen --allow-cors first?
unless I missed that somewhere
Hmm, makes sense to me, yeah
ok, let me check with Julian to see what the effort of doing something like this looks like
Discussing with @grim tide about the implementation, we realized it's a bit more tricky than thought.
It should take one or two days to implement. If it's a requirement for post-meetup we can add it to the backog, wdyt?
Are we okay to push to zenith-functions right now? Or should I wait until after the meetup? Won't push anything until I hear back on this either way.
Asking because I just finished cleaning up a few egregious hacks in the dagger shell implementation, towards the effort of merging that PR ASAP
Yeah you can push, assuming there are no known issues of course
There is no large-scale hackathon, mostly talking and showing demos
Definitely not urgent. We'll show as-is during the meetup. To be discussed with all the other ideas post-meetup π
Hahaha I just ran into this here and was thinking it would be in my demo tomorrow at Devoxx Morocco...does it work now with the right incantations?
#daggernauts message
I'll let you know when I finish the dialog with the instructions to set everything up locally!
Of course, if you think of any new feature you'd like to see for tomorrow, let me know
anything related to Java π
Excited that JC Sirot (the Java SDK author) might push a Zenith module! π€
By far the most urgent requirement for zenith demos is great CLI support for calling functions
(live feedback from meetup)
as I cringe watching amazing modules look unfairly complicated because of obscure raw graphql hacks
I think we should make this a collective sprint actually
pushed a few ux improvements to the zenith playground
thanks @tawny venture for the feedback!
@tardy belfry if you follow the steps in the dialog to spin up a local engine, it should work properly
A huge thank you to everyone who helped prepare!