#ci-next.exs
cinder rapids
I believe a little change from this version is to switch from dagger_ex to use dagger (https://hex.pm/packages/dagger). 🙂
tired bronze
Great, will change that tonight 🙂
Awesome that it's an (experimental) official sdk now, too bad it seems that no-one is interested/uses it (I found very little on the internet about it)
Just wanted to verify if it is/was still a good approach, or if things changed since then
cinder rapids
Oh, I just see the one breaking change. Let me update in a few minutes!
cinder rapids
New version updated https://gist.github.com/wingyplus/ffa1f7b8f6a548715b9a11501f632c14. 🙂
tired bronze
That is amazing. I will try later tonight and report back! Thank you so much for your swift help with this!
tired bronze
That worked, amazing. I just need to figure out how to push to (my own private) registry, but that should be easy enough
I have a lot of warnings like this:
┃ warning: Dagger.Directory.directory/2 is undefined (module Dagger.Directory is not available or is yet to be defined)
┃ lib/mix/tasks/dagger.test.ex:69 ```Also I seem to be triggering full mix recompiles very often (even when just changing the dagger pipeline code), is there a trick to reduce this and have it cache it better?
Especially all the dependencies should not be required (without changes to mix.exs)
cinder rapids
Also I seem to be triggering full mix recompiles very often (even when just chan...
You need to use https://hexdocs.pm/dagger/Dagger.Client.html#cache_volume/2 together with https://hexdocs.pm/dagger/Dagger.Container.html#with_mounted_cache/4 to cache deps and _build directory.
cinder rapids
That worked, amazing. I just need to figure out how to push to (my own private) ...
The private registry need docker login first, the dagger engine will use credentials from it.
cinder rapids
I have a lot of warnings like this:
```
┃ warning: Dagger.Directory.directory/2...
Do the mix clean help solve the problem?
tired bronze
Do the `mix clean` help solve the problem?
Nope, I did paste your example code inside a mix task (per official docs)
cinder rapids
That’s weird. It’s presented at https://hexdocs.pm/dagger/Dagger.Directory.html#directory/2. The warning should not appear. 🤔
tired bronze
I have this warning for every function from the library, I probably did something odd with my imports
cinder rapids
I add the mix task version to the gist hope its help https://gist.github.com/wingyplus/ffa1f7b8f6a548715b9a11501f632c14#file-dagger-test-ex
I tested with fresh phoenix application (with no ecto), it may different from your application.
cinder rapids
It's problably because of the task copy release from _build which's living inside the cache volume (https://gist.github.com/everte/262bd91e1ae3cea23bfe9f5e3078ce5b#file-dagger-ex-L80) and dagger is not allowed to copy from cache volume directly.
The possible solution that I can think at the moment is just copy the release bundle to outside and uses it instead. I post a solution into your gist https://gist.github.com/everte/262bd91e1ae3cea23bfe9f5e3078ce5b?permalink_comment_id=4801943#gistcomment-4801943. Hope this can help.
cinder rapids
Did you try mix deps.clean --all?
I try on my machine but no luck to see the huge warnings like your build. 😦
tired bronze
Jup, even after mix deps.clean --all.Odd but not a dealbreaker 🙂
tired bronze
Hmm, one tiny issue left, I seem to be missing the bin/migrate bin/server
cinder rapids
Hmm, one tiny issue left, I seem to be missing the bin/migrate bin/server
Not sure where it is locate but we can find and copying it from the builder container. It should not be hard.
tired bronze
Hmm, still needs some tweaking. I had to remove the caching because it was caching too good
tired bronze
Not sure where it is locate but we can find and copying it from the builder cont...
They are copied I think:
|> Container.with_directory("rel", Directory.directory(project, "."))