Great content on this channel. Keep up the good work! On a completely different side-note, I love your terminal/shell settings. Any chance of sharing your .zshrc file, plugins and themes? I'm especially interested in that bottom status bar and how it could be used to always show contextual information like the current kubernetes context. Thank you.
Thanks! Both for liking the channel and the setup ;) So, this response might get a little longer, but I'll try to list all the interesting parts: - The .zshrc is a standard oh-my-zsh file. I do have the git and kubectl plugins enabled, but only for the auto-completion and aliases, they don't change anything visually. The ZSH_THEME is set to the default "robbyrussell", for completeness, here's the link: github.com/etiennedi/dotfiles/blob/1c2011c4889f4195382dd3a32055586b049cbab0/.zshrc - The terminal uses the "Solarized Dark" colorscheme, I believe it's a default iTerm theme, but should be available for most terminals (vim uses the inverted theme, i.e. solarized light - I love the contrast between command line and vim) - The status bar at the bottom of the screen is coming from tmux. I use tmux mostly because I don't want to use the mouse and can use tmux to switch panes, windows and best of all select random text from the screen using vim-like commands. The tmux plugin for the status bar is a pretty common powerline plugin, my .tmux.conf is not very long, you can check it out here: github.com/etiennedi/dotfiles/blob/1c2011c4889f4195382dd3a32055586b049cbab0/.tmux.conf - Using the status bar for kubernetes-related info should be possible. Here's a tmux plugin that was mentioned on reddit the other day: github.com/jonmosco/kube-tmux I haven't tried it out myself, but it looks like it would do exactly what you asked :)
Hello. Thanks for the video. What's best practice for using docker and CI? I mean should we install dependencies, compile project in CI and after that wrap dist in docker container or we should do build steps in docker?
Thanks for the video, I have simple question. In the Dockerfile, for the caching purpose, we copy package and package lock to the working directory, then install it. It's going to generate node modules after installing it, what I'm wondering is, if you then execute COPY . . , then wouldn't it overwrite the modules that we installed previously?
That's great, but at the moment in our CI (gitlab) we have separate stages. First we pull dependencies, then run tests and lints in parallel, then we build application and finally we build docker image and push it to registry. Each of the stages are being run in docker containers and the final docker build is a docker-in-docker. Do you think we can somehow improve this build with a docker cache? We could put it all in single Dockerfile, along with tests and lints, but we lose clear indication what went wrong... and it just seems strange to do so.
Might be difficult with real docker-in-docker (i.e. own docker-deamon inside a container). With docker-outside-of-docker, i.e. shared socket you could also share the docker chaching abilities. I agree, benefiting from caching is nice, but not at the cost of losing visibility into which tests are breaking, etc. I haven't used GitLab CI too extensively yet, so I don't know if there are any tricks specific to it. How long are your builds on average?
Oh, we do share docker socket. At the moment, the build takes about 18 minutes, but currently we only have one runner. Having 2 runners should theoretically reduce the time by almost half. But since we are building more than one docker image and sometimes only one of them changes, I think we could gain a lot here. Even when the source code changes, but not the dependencies, we could still benefit from caching npm install. But - as said above - we don't know how to do it without putting it all in single Dockerfile. And that's something I try to figure out at the moment. Btw, thanks for the YT content and for answering my comment. Much appreciated!
This video is 3 years old found it now.
And you have awesome content on your channel.
Another possible optimization is to use "npm ci" instead of "npm install" which is significantly faster
Great content on this channel. Keep up the good work!
On a completely different side-note, I love your terminal/shell settings. Any chance of sharing your .zshrc file, plugins and themes? I'm especially interested in that bottom status bar and how it could be used to always show contextual information like the current kubernetes context.
Thank you.
Thanks! Both for liking the channel and the setup ;) So, this response might get a little longer, but I'll try to list all the interesting parts:
- The .zshrc is a standard oh-my-zsh file. I do have the git and kubectl plugins enabled, but only for the auto-completion and aliases, they don't change anything visually. The ZSH_THEME is set to the default "robbyrussell", for completeness, here's the link: github.com/etiennedi/dotfiles/blob/1c2011c4889f4195382dd3a32055586b049cbab0/.zshrc
- The terminal uses the "Solarized Dark" colorscheme, I believe it's a default iTerm theme, but should be available for most terminals (vim uses the inverted theme, i.e. solarized light - I love the contrast between command line and vim)
- The status bar at the bottom of the screen is coming from tmux. I use tmux mostly because I don't want to use the mouse and can use tmux to switch panes, windows and best of all select random text from the screen using vim-like commands. The tmux plugin for the status bar is a pretty common powerline plugin, my .tmux.conf is not very long, you can check it out here: github.com/etiennedi/dotfiles/blob/1c2011c4889f4195382dd3a32055586b049cbab0/.tmux.conf
- Using the status bar for kubernetes-related info should be possible. Here's a tmux plugin that was mentioned on reddit the other day: github.com/jonmosco/kube-tmux I haven't tried it out myself, but it looks like it would do exactly what you asked :)
Great video, but can this technique also be use in asp core nuget restore scenario?
Hello. Thanks for the video.
What's best practice for using docker and CI? I mean should we install dependencies, compile project in CI and after that wrap dist in docker container or we should do build steps in docker?
What shell are you using? Looks very cool.
Thanks for the video, I have simple question.
In the Dockerfile, for the caching purpose, we copy package and package lock to the working directory, then install it.
It's going to generate node modules after installing it, what I'm wondering is, if you then execute COPY . . , then wouldn't it overwrite the modules that we installed previously?
Awesome video
That's great, but at the moment in our CI (gitlab) we have separate stages. First we pull dependencies, then run tests and lints in parallel, then we build application and finally we build docker image and push it to registry. Each of the stages are being run in docker containers and the final docker build is a docker-in-docker. Do you think we can somehow improve this build with a docker cache? We could put it all in single Dockerfile, along with tests and lints, but we lose clear indication what went wrong... and it just seems strange to do so.
Might be difficult with real docker-in-docker (i.e. own docker-deamon inside a container). With docker-outside-of-docker, i.e. shared socket you could also share the docker chaching abilities. I agree, benefiting from caching is nice, but not at the cost of losing visibility into which tests are breaking, etc. I haven't used GitLab CI too extensively yet, so I don't know if there are any tricks specific to it. How long are your builds on average?
Oh, we do share docker socket. At the moment, the build takes about 18 minutes, but currently we only have one runner. Having 2 runners should theoretically reduce the time by almost half. But since we are building more than one docker image and sometimes only one of them changes, I think we could gain a lot here. Even when the source code changes, but not the dependencies, we could still benefit from caching npm install. But - as said above - we don't know how to do it without putting it all in single Dockerfile.
And that's something I try to figure out at the moment.
Btw, thanks for the YT content and for answering my comment. Much appreciated!