Hi @Addshore! @nnikkhoui is digging into the vuejs-components Docker implementation and had a few questions. I, ah, can't seem to find the WMDE contact list page any more but I think(?) you'd be the best person to talk about it. Would it be possible for y'all to meet and discuss?

Hey @Niedzielski ! thanks a lot for searching the collaboration!! The WMDE contact list is being worked on at the moment, apologies for the inconvenience :)

I have the impression that one of the teammates that has been involved in the recently implemented DS at WMDE (@Jakob_WMDE , @Tonina_Zhelyazkova_WMDE, @Pablo-WMDE) may add some really valuable insights for that. I am assuming you would like to have the call soon?

Hi @darthmon_wmde, I didn't have too many crazy questions just a couple general ones about how it is configured. We could do async or sync conversation about it if anyone on the team would be willing to help me out!

I had a general question around the use of docker-compose in the vuejs-components project. (From my understanding) docker-compose is useful when you need multiple docker containers running together, but in the case of your project I was wondering if the same thing could be accomplished with a single container, by just using a Dockerfile? In the docker-compose.yml for example, it looks like the node service is mounting some volumes and storybook service is actually getting the storybook service running on port 3003. How come 2 containers are needed in this case? And would it be bad practice to combine them both in a single container?

Hi @nnikkhoui,

I pretty much agree with your reasoning about other options how the task at hand could be accomplished, but you also already hinted that it is good practice to "separate areas of concern by using one service per container".

While this seemingly adds some complexity (especially when not having used docker-compose before), in my eyes it pays back quickly when hunting bugs or later tweaking individual configurations. It also gives you the slightly better performance in case you are actually only interested in one of the services and start it up in isolation. In our case it additionally has the benefit of resulting in identical commands us devs run (and reuse from shell history) across our various TS applications, some of which actually requiring service composition (e.g. termbox).

It should be noted that there is no tension between using docker-compose for some use cases and docker - to run a single container - for others (you could e.g. tag the image when built through docker-compose and then docker run as usual in what ever task where this would be more convenient). However, you should at least give docker-compose a try - if only for the sugar of not having to manually specify mounts, ... time and again.

All use cases are not alike, so if you want to bounce ideas, let us know!

Cheers

I appreciate the response @Pablo-WMDE. My questioning came from not wanting to over-complicate the solution, and making sure docker-compose was the appropriate tool for our use case. But I agree with what you said, developing locally through a UI (storybook) and doing the project build is beneficial. I will move ahead with docker-compose, thank you!

Change 624267 had a related patch set uploaded (by Nikki Nikkhoui; owner: Nikki Nikkhoui):
[wvui@master] Add blubber config and docker configs

https://gerrit.wikimedia.org/r/624267

Change 624267 merged by Niedzielski:
[wvui@master] Add blubber config and docker configs

https://gerrit.wikimedia.org/r/624267

@nnikkhoui's patch^ adds a docker-compose config to WVUI. It includes a Node.js container for installing dependencies and building, as well as a Storybook container for development.

The containers are dumb, transparent, and optional locally (but they should be used whenever upgrading NPM dependencies at least). By dumb and transparent, I mean that you don't have to have a degree in RelEng to use them. They mount portions of the repo root as a container volume and read and write files there. That's it. The benefits are that all host operating systems should have a highly reproducible build and development environment. Some separation from the host (no access to .ssh, for example) is also provided for better security, similar to Timo's fresh project and others.

Nikki's patch also includes a Blubber config for a forthcoming CI integration. That is, Jenkins will run npm test inside the container. That's the next step in this task.

The process of developing the solution identified some additional future improvements to explore (some captured here and in T263787):

• Adding a production container configuration.
• Automatically pick better default values of environment variables used by the containers.
• Use the containers in the release scripts.
• Not specific to containers but came up again: understand what folks want regarding Git pre-commit hook tests: on, off, or optional but on by default. Vector's feat/search branch takes the optional but on by default approach. WVUI takes the on approach. Most Wikimedia repos take the off approach. Pre-commit tests are used to validate changes locally before pushing patches to encourage a minimum level of quality prior to signaling reviewers. However, the step can be replaced by simply remembering to test (npm t && git commit).

The patch is a nice exploration into using containers for a WMF codebase. If we continue using containerization, we'll definitely want to collaborate much more closely with WMDE post-search, which is further along than WMF and has provided numerous invaluable insights. Please see the readme for more details.

Change 630624 had a related patch set uploaded (by Jforrester; owner: Nikki Nikkhoui):
[wvui@master] Pipeline config

https://gerrit.wikimedia.org/r/630624

Change 630624 had a related patch set uploaded (by Nikki Nikkhoui; owner: Nikki Nikkhoui):
[wvui@master] Pipeline config

https://gerrit.wikimedia.org/r/630624

Change 630624 merged by jenkins-bot:
[wvui@master] Pipeline config

https://gerrit.wikimedia.org/r/630624

Change 630948 had a related patch set uploaded (by Nikki Nikkhoui; owner: Nikki Nikkhoui):
[wvui@master] Production Blubber Config

https://gerrit.wikimedia.org/r/630948

Change 630948 merged by jenkins-bot:
[wvui@master] Production Blubber Config

https://gerrit.wikimedia.org/r/630948

post-merge verified the project's /dist folder was identical between local Docker development build vs. Blubber Docker development build.

Web had some prior discussion with the Release-Engineering-Team regarding this task and T257582 on and off thread. I think @nnikkhoui has also been collaborating with y'all already so hopefully none of this is news but Nikki has the WVUI repo fully containerized and Blubberized at this point. That is, patches submitted to the WVUI repo are now built and tested. 🎉

What's next? Nikki will be working to explore what options exist to actually extract the build artifacts from the containers and publish them somewhere (T264244), generally improving the containers in T263787, mimicking the Blubbability added here and publishing the artifacts in Vector (T257582), and publishing WVUI docs to doc.wikimedia.org (T255678) as time allows. If you have any requests or concerns, please let us know or open a new task.

Thank you to @JoeWalsh, @dcipoletti, @jeena, @Pablo-WMDE, @dduvall, @thcipriani, @Jdrewniak, @santhosh, @darthmon_wmde, @LarsWirzenius, @WMDE-leszek (and everyone else!) for all the support on and off thread! 👍