This commit updates our `build` workflow to push the following manifests
which can be used to run Discourse against the stable branch.
1. discourse/base:2.0.$TIMESTAMP-stable
2. discourse/base:release-stable
Co-authored-by: David Taylor <david@taylorhq.com>
- makes decision based on current state of directory, instead of `$version`
- cleans up the correct directories
- only cleans up the contents. This is important if node_modules directores are mounted volumes (e.g. in devcontainer)
This commit updates 2 things.
1. Updates the yarn hook to replace the npm mirror before `pnpm install`.
2. Removes the `yarn.lock` patch as pnpm is now used.
After applying these modifications, I successfully installed Discourse on the Tencent Cloud China server. No more network problems.
Add an option to select a targeted namespace, env var DISCOURSE_NAMESPACE
Configure:
Add `source-tag` to select which tag to configure from.
Rename old `tag` option to `target-tag` to differentiate from `source-tag` option
Migrate:
Add `tag` to select which tag to migrate with
When running the newer Debian bookworm based images, we are seeing
`(ThreadError) can't create Thread: Operation not permitted` errors when
trying to spawn a thread in Ruby.
A similar issue was reported in https://github.com/docker-library/ruby/issues/429#issuecomment-1708908819
and the fix here is to upgrade Docker. Either way, we should probably
update because Docker 17 has been EOF for many many years.
adds commands for: start, run, stop, cleanup, destroy, logs, enter, restart, rebuild -- carrying over existing run commands from launcher1.
Rebuild will also do its best to minimize downtime with the following steps:
* Detect if Discourse is running as a single container or external DB
* Detect if db:migrate is configured to run on container boot
* Build initial container (keeping existing one online)
* Exit running containers if it's a single container (otherwise keeps existing online)
* Run migrations
* Defer migrations if db:migrate is configured to run on container boot
* Run migrations with SKIP_POST_DEPLOYMENT_MIGRATIONS=1 if it's a 2 container setup
* Otherwise, run all migrations
* Destroy the old container (finally stopping the current, if it's still up here)
* Start the new container
* Run post-deploy migrations
* Run migrations with SKIP_POST_DEPLOYMENT_MIGRATIONS=0 if it's a 2 container setup
Add 'configure' command - If run after the "build" command, this is equivalent to today's 'bootstrap' command.
Note that unlike build command, a docker run+commit pattern needs to be used here as this requires a running database + mounted volumes.
- Combines dev image build into the `base` job
- Calculates a single timestamp for all builds
- Pushes timestamped per-arch images to Dockerhub for base, base-slim and dev images
- If both arch build jobs are successful, multiarch manifests are generated & pushed
When updating to `debian/base:bookworm` from `debian/base:bullseye`, we
noticed that the uid of the `postgres` and `redis` user changed leading
to permission issues when trying to access directories of mounted volumn
which was previously created with the old uid. The change is because the
`_apt` user is assigned a uid of `42` in Debian bookworm instead of `100`
in Debian bullseye. As a result, the `postgres` user created by the `postgres`
package is automatically assigned a uid of `100` in Debian bookworm instead of `101` in Debian
bullseye.
This commit updates the `slim.Dockefile` to manually add the `postgres`
user and group assigning it a gid of `104` and uid of `101`. The `redis`
user and group is assigned a uid of `103` and a gid of `106`. The
`discourse` user and group is assigned a uid of `1000` and gid of
`1000`.
We use this on the main core repository, so it makes sense to use it here as well. It should reduce the overall flakiness of the discourse_docker build.
- Remove manual database creation, and instead promote discourse user to postgres SUPERUSER. This means that `db:drop` and `db:create` commands can be run in the dev image, just like in other local development environments. As well as simplifying things, it fixes turbo_rspec, which was previously impossible in the docker dev environment (because `discourse` didn't have permissions to create the parallel databases)
- Stop pre-migrating test database in dev image. It adds additional build time & image size, and doesn't actually help because core's `bin/docker/boot_dev` script overwrites the container's postgres directory with a volume mount
* FIX: Variable isn't being set
* DEV: Goodbye tabs, they're probably feeling lonely anyway
* FIX: Variable is never used. No need for command substitution
* FIX: The likelihood of knowing the PID for the script before execution is exceptionally low
add tab completion for launcher and discourse-setup.
For launcher, offers command (e.g., rebuild, start) and then offers yml files from containers directory. After that switches (e.g., --run-image) are offered. (Will not offer switches except in final position, sorry.)
discourse-setup offers switches (e.g., --two-container).
discourse-docter has no command line arguments.
when we have already run an initial setup, fall back to just checking for
socket, rather than outright failing if the init script has already been run.
This allows 'configure' steps to be re-run in standalone cases.
eg: `launcher2 configure app && launcher2 configure app`
current version: fails as it's missing the install_postgres file
with PR: checks for psql socket, and builds.
doing something like `launcher2 start app && launcher2 configure app` would also
print out a more correct error message, "postgres already running stop container"
We started installing Chromium because there is no linux ARM support
for Chrome yet. However, trying to run tests on Chromium seems to be
extra challenging. For example, upgrading to Debian 12 causes our
Javascript tests to fail on Chromium but not on Chrome.
Chrome for Testing was built specifically for web app testing so let's
follow Google's recommendation.
We need to upgrade to bookworm because bullseye is EOL. This commit when merged into branch will push the following images to Docker hub:
1. `discourse/base:slim-bookworm`
2. `discourse/base:release-bookworm`
3. `discourse/discourse_test:slim-bookworm`
4. `discourse/discourse_test:slim-browsers-bookworm`
5. `discourse/discourse_test:release-bookworm`
This fixes a regression introduced in
bbefa1e5f3. Basically, we cannot configure
the default bundle jobs when building the image because the number of
cores used to build the image can be different from the number of cores
on the machine running the image.
A number of people have reported hitting yarn timeouts on low-spec DO droplets, which causes the build to fail. This should provide a little more leeway
Alan Guo Xiang Tan
David Taylor
Jeff Wong
cheungtitus
Jeremy
Pablo Ganuza Vidal
Derek J. Lambert
Jay Pfaffman
Rafael dos Santos Silva