Description
-----------
A while ago I asked on Discord if you people would be interested in removing incompatibilities with rootless docker. See: https://discord.com/channels/979116623879368755/1071165397228855327/1442974448776122592
The e2e tests in `e2e/src/api/specs/oauth.e2e-spec.ts` depend on a docker feature [host-gateway](https://docs.docker.com/reference/cli/dockerd/#configure-host-gateway-ip) that seemingly does not work on rootless docker.
So the suggested change is to dockerify the `auth-server` and not run it on the docker host.
I would love to receive feedback on this PR and feel free to request further improvements. Things that come to my mind:
* Compile typescript instead of using `tsx`
* Add hot-reloading of source files in `auth-server/` for development
* Add `eslint` configuration for the new folder
How Has This Been Tested?
------------------------
I'm running both default and rootless docker on my machine with [docker contexts](https://docs.docker.com/engine/manage-resources/contexts/):
```
docker context ls
NAME DESCRIPTION DOCKER ENDPOINT ERROR
default unix:///var/run/docker.sock
rootless * unix:///run/user/1000/docker.sock
```
If I follow the steps from the [documentation](https://docs.immich.app/developer/testing) then `oauth.e2e-spec.ts` will fail because the `auth-server` on my host can't be reached.
The tests pass after these steps:
1. `git switch refactor-auth-server-as-service`
2. `make e2e`
3. In another terminal `cd e2e`
4. `pnpm run test src/api/specs/oauth.e2e-spec.ts` passes
Checklist:
----------
- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation if applicable
- [x] I have no unrelated changes in the PR.
- [ ] I have confirmed that any new dependencies are strictly necessary.
- [ ] I have written tests for new code (if applicable)
- [ ] I have followed naming conventions/patterns in the surrounding code
- [ ] All code in `src/services/` uses repositories implementations for database calls, filesystem operations, etc.
- [ ] All code in `src/repositories/` is pretty basic/simple and does not have any immich specific logic (that belongs in `src/services/`)
Description
-----------
When I follow the [developer setup](https://docs.immich.app/developer/setup) I run into a permission error using rootless docker. A while ago I asked on Discord in [#contributing](https://discord.com/channels/979116623879368755/1071165397228855327/1442974448776122592) about these ulimits.
I suggest to remove the `ulimits` altogether. It seems that @ItalyPaleAle has left the setting just hoping that it could help somebody in the future. See the [PR description](https://github.com/immich-app/immich/pull/4556).
How Has This Been Tested?
-------------------------
Using rootless docker:
```
$ docker context ls
NAME DESCRIPTION DOCKER ENDPOINT ERROR
default unix:///var/run/docker.sock
rootless * unix:///run/user/1000/docker.sock
```
Running `make` will fail because of permission errors:
```
$ docker compose -f ./docker/docker-compose.dev.yml up --remove-orphans
...
Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting rlimits for ready process: error setting rlimit type 7: operation not permitted
```
On my machine I have the following hard limit for "Maximum number of open file descriptors":
```
$ ulimit -nH
524288
```
I can confirm that the permission error is caused by the security restrictions of the operating system mentioned above:
Changing `docker/docker-compose.dev.yml` like ..
```
ulimits:
nofile:
soft: 524289
hard: 524289
```
.. will lead to a permission error whereas this ..
```
ulimits:
nofile:
soft: 524288
hard: 524288
```
.. starts fine.
Apparently the defaults for these limits are coming from [systemd](https://github.com/systemd/systemd/blob/26b2085d54ebbfca8637362eafcb4a8e3faf832f/man/systemd.exec.xml#L1122) which is used on nearly every linux distribution. So my assumption is that almost any linux user who uses rootless docker will run into a permission error when starting the development setup.
Checklist:
----------
- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation if applicable
- [x] I have no unrelated changes in the PR.
- [ ] I have confirmed that any new dependencies are strictly necessary.
- [ ] I have written tests for new code (if applicable)
- [ ] I have followed naming conventions/patterns in the surrounding code
- [ ] All code in `src/services/` uses repositories implementations for database calls, filesystem operations, etc.
- [ ] All code in `src/repositories/` is pretty basic/simple and does not have any immich specific logic (that belongs in `src/services/`)
Description
-----------
The documentation lies about comments in `docker/docker-compose.dev.yml`.
Reason: in 689c6aa276 these docs were added
but the comments in this file are removed in
b9e2590752 and the docs weren't updated.
How Has This Been Tested?
-------------------------
```
$ git log -S rootless
commit b9e2590752
Author: Jason Rasmussen <jason@rasm.me>
Date: Tue Sep 16 12:48:44 2025 -0400
chore: simplify (#22082)
commit 689c6aa276
Author: Rudolf Horváth <R-Rudolf@users.noreply.github.com>
Date: Thu Nov 21 13:25:45 2024 +0100
docs: add developer notes about rootless docker setup (#13250)
```
Checklist:
----------
- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation if applicable
- [x] I have no unrelated changes in the PR.
- [ ] I have confirmed that any new dependencies are strictly necessary.
- [ ] I have written tests for new code (if applicable)
- [ ] I have followed naming conventions/patterns in the surrounding code
- [ ] All code in `src/services/` uses repositories implementations for database calls, filesystem operations, etc.
- [ ] All code in `src/repositories/` is pretty basic/simple and does not have any immich specific logic (that belongs in `src/services/`)
Motivation
----------
It's a follow up to #10028. I think it would be better user experience if one can tell by the icon what the delete button is about to do.
I hope I caught all the occurences where one can permanently delete assets.
How to test
-----------
1. Visit e.g. `/trash`
2. If you select some assets, the delete button in the top right corner
looks different.
Motivation
----------
I guess these make targets should have been deleted in 57136e48fb.
How to test
-----------
1. Nothing really, this removes dead code
Motivation
----------
For me as a new contributor it is frustrating to submit a PR and it will always fail. Even worse: I have to wait for another contributor with more power to assign the label for me.
This will improve developer experience, as some of the labels can be assigned automatically based on changed files.
How to test
-----------
1. Merge this PR
2. Submit a couple of PRs with changes in the respective directories
3. Labels should be automatically applied
4. "Enforce PR labels" github workflow will re-run when "Pull Request Labeler" completes
* fix: prevent trashing of trashed assets
Motivation
----------
This will improve user experience by hiding a pointless action.
You can not trash a trashed asset again. It won't get any trashier than it already is.
How to test
-----------
1. Visit route `/trash`
2. Click on an asset
3. Press "Delete" on your keyboard
4. Nothing happens
5. Try to find the trash button in the top right
6. You can't find it
* refactor: follow @michelheusschen's review
See:
https://github.com/immich-app/immich/pull/10028#pullrequestreview-2105296755
* refactor: follow @michelheusschen's 2nd review
See: https://github.com/immich-app/immich/pull/10028#discussion_r1632057833
* docs: Add pgadmin4 to docker-compose.yml
Motivation
----------
The current documentation encourages to install pgAdmin3 on the host
system. It's much simpler to add `pgAdmin4` to the `docker-compose.yml`:
1. No configuration needs to be modified, just added.
2. Better security because no additional ports need to be opened on the host.
3. Easier installation. E.g. on Archlinux there is no package pgAdmin3
anymore.
4. `pgAdmin3` does not seem to be maintained.
How to test
-----------
1. Follow the documentation.
2. See if you can connect to the immich database
* docs: better use separate config file
I assume most users will not edit the `docker-compose.yml` and forget
about `pgAdmin` once they're done. So, `pgAdmin` might get exposed to
the internet with default credentials, which is not good.
Better to leave a hint to change the credentials and keep the
configuration separate, so users start `pgAdmin` knowingly and turn it
off once they're done.
Motivation
----------
Looks like `npm` is being used, `package-lock.json` is checked in
whereas `yarn.lock` is gitignored.
So, let's use `npm` in the README.
How to test
-----------
1. Follow the README.
2. It behaves just like before.
