You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Developer-Guide--Set-Up-With-Docker.md
+79-2Lines changed: 79 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -203,14 +203,91 @@ If you plan on doing work that involves sending/recieving emails from MarkUs, yo
203
203
204
204
**Note: This is an archive of problems related to Docker that are encountered by students, and their solutions.**
205
205
206
-
### Q
206
+
### Q1
207
207
208
208
I'm writing frontend code. The files I've changed should according to the Webpack config files trigger Webpack rebuild, but that's not happening. I've verified that
209
209
210
210
1. My changes are valid and should be displayed from the URL I'm accessing.
211
211
2. There are no errors in the Webpacker container's logs.
212
212
3. If I run `npm run build-dev` in the Webpacker container's console directly, it succeeds and I'm able to see my changes afterwards.
213
213
214
-
### A
214
+
### A1
215
215
216
216
*This solution is experimental and could lead to problems such as higher CPU usage.* This is likely due to Webpack's `watch` option not working properly. According to the official Webpack [docs](https://webpack.js.org/configuration/watch/#watchoptionspoll), one suggestion when `watch` is not working in environments such as Docker, is to add `poll: true` to `watchOptions` inside the Webpack config file, which in our case, is `webpack.development.js`. This should help resolve the problem.
217
+
218
+
### Q2
219
+
220
+
When I run `docker compose up rails`, or when I restart my previously created `rails` container, I get a warning/error along the lines of
221
+
222
+
```MARKDOWN
223
+
markus-rails-1 | system temporary path is world-writable: /tmp
224
+
markus-rails-1 | /tmp is world-writable: /tmp
225
+
markus-rails-1 | . is not writable: /app
226
+
markus-rails-1 | Exiting
227
+
markus-rails-1 | /usr/lib/ruby/3.0.0/tmpdir.rb:39:in `tmpdir': could not find a temporary directory (ArgumentError)
228
+
[...stacktrace]
229
+
```
230
+
231
+
after following the setup guide step by step. I've looked into my host setup and confirmed that my `/tmp`'s permissions are correct (i.e. on Linux you can expect a 1777, on mac it might be a symbolic link to `/private/tmp`, latter of which would also be a 1777). For the second warning/error, I've found that my Markus container's `/app` is owned by `root`, not `markus`.
232
+
233
+
### A2
234
+
235
+
It's unclear exactly why or how this occured, but one fix is as simple as using another directory for this purpose. Ruby reads a variety of environment variables (env vars) to determine the system's temporary directory that it can use, and you can customize that directory with an env var. Both warnings/errors are complaining about the same thing: no available `TMPDIR`.
236
+
237
+
Since this is not a wide-spread issue, it's more reasonable to have the setup living entirely on your local (i.e. ignored by git) than committing it to the repo.
238
+
239
+
1. Start by creating a `docker-compose.override.yml` file under Markus root. Notice that the filename is already listed in `.gitignore`.
240
+
2. The general idea is simple - configure `TMPDIR`, then pass this configuration in. Now we need to find a potential `TMPDIR` candidate inside the container. Reading <https://github.com/ruby/ruby/blob/ruby_3_0/lib/tmpdir.rb> gives us an idea of what ruby expects (at the time of writing, Markus was in ruby 3.0, but this file shouldn't expect major changes in the future versions. If it starts using other env var(s), update this documentation to reflect the new env var(s)).
241
+
3. You can find a directory in the rails container with the correct permissions (1777) & that is unused by Markus, or create your own. In my case `/var/tmp` fit the profile.
242
+
1. I found the directory by starting a shell in the `rails` container with `docker exec -it` and then running `find -type d -perm 1777`
243
+
4. Write this env var into the `docker-compose.override.yml` file you created. For example:
244
+
245
+
```YAML
246
+
version: '3.7'
247
+
248
+
services:
249
+
rails:
250
+
environment:
251
+
- TMPDIR=/var/tmp
252
+
```
253
+
254
+
5. Save your changes. After `docker compose build app`, make sure you run `docker compose -f docker-compose.override.yml docker-compose.yml up rails` instead of just `docker compose up rails`. This will apply the `TMPDIR` we created, which would resolve the issue.
255
+
256
+
### Q3
257
+
258
+
When the `rails` container is started, postgres' database migrations will be auto applied because of the line `bundle exec rails db:prepare` in `entrypoint-dev-rails.sh`. Sometimes migrations fail - sometimes outright when you first start the container with `docker compose up rails`, other times when you successfully create your `rails` container, then make some data change to markus (i.e. adding a new assignment tag) or shut down and restart the `rails` container - like
This would also occur after following the setup guide step by step.
276
+
277
+
### A3
278
+
279
+
Again, it's unclear exactly why this happened, but there's a fix.
280
+
281
+
1. If you're running into the first one, it's likely because your migrations were applied successfully the first time, but because of some unknown (likely permission) issues, postgres didn't record those migrations as complete, so next time the db is refreshed, postgres would attempt the migrations again.
282
+
2. Verify the cause. If you've taken CSC343, this should seem very familiar:
283
+
1. Start a shell inside the `postgres` container.
284
+
2. Run `psql -U [postgres username]`. At the time of writing, this username is postgres' image's default username, which is `postgres`. Consult `docker-compose.yml` first to check if another username has been specified.
285
+
3. You'll be prompted for the user's password, which you can find in `docker-compose.yml` as well.
286
+
4. Now you're in the postgres shell. Run `\c markus_development` to connect to the `markus_development` database. You can see the list of databases with `\l`.
287
+
5. On success, run `select count(*) from schema_migrations;`. Normally, the outputted count should be equal to the total number of migrations (files) under Markus/db/migrate. In this case, it might be 0 or a smaller number.
288
+
6. Repeat steps iv - v for `markus_test` as well, and the count should be the same.
289
+
290
+
3. The fix is rather simple as well. You will start with commenting out the line `bundle exec rails db:prepare` in `entrypoint-dev-rails.sh`.
291
+
4. Once `rails` container is up, start a shell inside it and run `bundle exec rails db:prepare`. Without running this, you won't be able to browse markus UI.
292
+
1. If for whatever reason this command fails, try `rails db:drop && rails db:create && rails db:migrate && rails db:seed` instead.
293
+
5. The downside is you'll have to redo this process every time the containers are recreated, but otherwise this should resolve the issue. Verify that the `schema_migrations` tables now contain the correct number of migration records.
0 commit comments