I’m getting this error when trying to run d/boot_dev --init
Errno::EACCES: Permission denied @ dir_s_mkdir - tmp
/src/config/boot.rb:23:in `<top (required)>'
/src/config/application.rb:16:in `require'
/src/config/application.rb:16:in `<top (required)>'
/src/Rakefile:7:in `require'
/src/Rakefile:7:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
(See full trace by running task with --trace)
Any ideas on how I fix it? Tried searching for it everywhere but didn’t find any solutions.
Edit: fixed it by doing chmod -R 777 ~/discourse, but now I’m getting this error:
gifsicle worker: gifsicle not found; please provide proper binary or disable this worker (--no-gifsicle argument or :gifsicle => false through options)
How to use plugins in this kind of setup?
I am trying to follow Install Plugins in Discourse, but it mentions /var/discourse/containers/app.yml file, which does not exist in my discourse directory.
I’ve got building a discourse dev environment working and able to test my patch, but how do I get my patch into my production instance? I tried building base, and then ./launcher rebuild app --run-image discourse/base:build, but it doesn’t seem to result in a running Discourse instance.
Usually I get an error about the syslog group missing, but I commented that out, and still didn’t end up with a running site. And nothing of note in docker logs.
We don’t really document this kind of stuff, but you would generate a “diff” file, the git apply the diff in a hook after you clone the repo. app.yml supports hooks.
A quick-and-dirty solution for self hosted single container things is just to edit the code in place and run sv restart unicorn
Not sure if this is the best place to ask about this problem but I’ve been unable to finish the Discourse installation using Docker on an Apple M1 computer.
After I run d/boot_dev --init all dependencies are installed without any apparent problem but once I get to the Migrating database step, it stays there consuming 100% of one of my cores and it doesn’t seem to move from there.
I tried logging in to the docker container and the bundle migrate task is running at 100% but no apparent activity on the posgresql process.
I tried briefly today, and got stuck at the same step as you, but with an error:
Invalid gemspec in [/usr/local/lib/ruby/gems/2.7.0/specifications/default/zlib-1.1.0.gemspec]: Malformed version number string specification_version
bundler: failed to load command: rake (/usr/local/bin/rake)
Yes, please do. There are multiple team members using Discourse on M1 (myself included) every day, so it works quite well!
I tried this today, and also ran into issues. The error I saw was because Docker’s architecture emulation doesn’t support inotify (which we use a lot in Discourse development). For now, I’ve added a warning to d/boot_dev when a non-x86_64 architecture is detected:
❯ d/boot_dev
WARNING: Docker architecture is not x86_64.
Discourse development is unlikely to work using Docker's architecture emulation.
Please try a native development installation.
I’ve now added a d/ember-cli helper, and forwarded port 4200 by default. The info at the top of this topis has also been updated. Once you’ve updated, run d/rails s in one terminal, and d/ember-cli in another. I’ve also set NO_EMBER_CLI as one of the variables which is passed through to Docker, so that is available if needed.
@david probs inconsequential but just FYI: The boot_dev script prints out a false error finding on the x86_64 check when I accidentally ran without Docker on…(but the ‘Is the docker daemon running’ part is right)…
WARNING: Docker architecture is not x86_64.
Discourse development is unlikely to work using Docker's architecture emulation.
Please try a native development installation.
...(snip)...
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Thanks for this image, and the super-clear instructions!
I got psql: error: FATAL: Peer authentication failed for user "postgres" when running d/boot_dev --init.
Although the pg_hba.conf in data/postgres/ had all the authentication methods set to “trust”, there was another one in /etc/postgresql/13/main/ which had the defaults (“peer” / “md5”).
I edited /etc/postgresql/13/main/pg_hba.conf, changed all the methods to trust, did d/shell and ran sv restart postgres to pick up the changes – and was able to continue by running d/bundle install; d/rake db:migrate RAILS_ENV=development; d/rake admin:create manually.
Leaving here in case it’s helpful for anyone else!
