Add docker development environment #1

Closed
lil5 wants to merge 6 commits from lil5:docker into main
lil5 commented 4 months ago

This uses docker to keep things consistent across platforms and create an easier way to get started.

This uses docker to keep things consistent across platforms and create an easier way to get started.
lil5 added 3 commits 4 months ago
fnetX requested changes 4 months ago
fnetX left a comment
Collaborator

Thank you for looking into this and providing this patch.

Since you are heavily using third-party dependencies, please either drop them or indicate that this guide is not audited or maintained by Codeberg but the community, and people should use everything outside the official instructions (= install go and do make) at their own risk.

Thank you for looking into this and providing this patch. Since you are heavily using third-party dependencies, please either drop them or indicate that this guide is not audited or maintained by Codeberg but the community, and people should use everything outside the official instructions (= install go and do `make`) at their own risk.
DEVELOPMENT.md Outdated
$ docker-compose up -d backend
```
**6. Start frontend**
fnetX commented 4 months ago
Collaborator

the app serves the frontend itself, I do not understand why you add this step. Even if this might be more convenient, it's definitely not a requirement at all!

the app serves the frontend itself, I do not understand why you add this step. Even if this might be more convenient, it's definitely not a requirement at all!
lil5 commented 4 months ago
Poster

As per:

filesDir := http.Dir(filepath.Join(workDir, "../frontend"))

Right I'll make some more changes to fix that, the documentation is not very explanitory conserning structure.

As per: ```go filesDir := http.Dir(filepath.Join(workDir, "../frontend")) ``` Right I'll make some more changes to fix that, the documentation is not very explanitory conserning structure.
fnetX commented 4 months ago
Collaborator

I don't even get how your change is supposed to work, as it uses a different port and the frontend can't possibly find the backend, can it?

The way the frontend is served is probably subject to change anyway. I'm considering to use templates e.g. to insert the app name there, or render some basic information (like recent actions), so it's also available to noscript users. In the future, it'll surely also be beneficial to compile the JS into a single file, but I won't deal with that until the app is actually usable and going to be deployed somewhere.

I don't even get how your change is supposed to work, as it uses a different port and the frontend can't possibly find the backend, can it? The way the frontend is served is probably subject to change anyway. I'm considering to use templates e.g. to insert the app name there, or render some basic information (like recent actions), so it's also available to noscript users. In the future, it'll surely also be beneficial to compile the JS into a single file, but I won't deal with that until the app is actually usable and going to be deployed somewhere.
lil5 commented 4 months ago
Poster

In docker a container has each, other, service listed in its host file thus they can talk directly using the service name.

This is the reason the url of the gitea must be changed to URL = http://gitea:3000 just like:

  gitea: <- this
    image: gitea/gitea:latest

Anyway the frontend step has now been removed and the backend service now includes the root project to allow go to read '../frontend'.

In docker a container has each, other, service listed in its host file thus they can talk directly using the service name. This is the reason the url of the gitea must be changed to `URL = http://gitea:3000` just like: ```yml gitea: <- this image: gitea/gitea:latest ``` Anyway the frontend step has now been removed and the backend service now includes the root project to allow go to read `'../frontend'`.
lil5 marked this conversation as resolved
services:
gitea:
image: gitea/gitea:1.16.5
fnetX commented 4 months ago
Collaborator

let's not hardcode this, if possible, but always stick to latest.

let's not hardcode this, if possible, but always stick to latest.
lil5 commented 4 months ago
Poster

Done

Done
lil5 marked this conversation as resolved
volumes:
- .:/usr/src/myapp
working_dir: /usr/src/myapp
command: sh -c 'go install github.com/githubnemo/CompileDaemon@v1.4.0 && CompileDaemon -exclude-dir=.git -exclude-dir=.gitea -build="go run ."'
fnetX commented 4 months ago
Collaborator

What does that third-party dependency do?

What does that third-party dependency do?
lil5 commented 4 months ago
Poster

Watches your .go files in a directory and invokes go build if a file changed. Nothing more.
https://github.com/githubnemo/CompileDaemon

I use it to live reload a go run . command on .go file changes.

> Watches your .go files in a directory and invokes go build if a file changed. Nothing more. > https://github.com/githubnemo/CompileDaemon I use it to live reload a `go run .` command on `.go` file changes.
fnetX marked this conversation as resolved
code.gitea.io/gitea-vet v0.2.1/go.mod h1:zcNbT/aJEmivCAhfmkHOlT645KNOf9W2KnkLgFjGGfE=
fnetX commented 4 months ago
Collaborator

this seems to be an unrelated change, and while exact version locking might be fine for releasing this into production, I don't think we should track these large files during the current development (bootstrapping) phase.

this seems to be an unrelated change, and while exact version locking might be fine for releasing this into production, I don't think we should track these large files during the current development (bootstrapping) phase.
lil5 commented 4 months ago
Poster

That conserns me why you would want to do that. Lock files keep devs from dealing with possible bugs relating to different versions used, keeping that to a minimum sounds like a good thing, on top of that how many KBs are we talking about?

That conserns me why you would want to do that. Lock files keep devs from dealing with possible bugs relating to different versions used, keeping that to a minimum sounds like a good thing, on top of that how many KBs are we talking about?
fnetX commented 4 months ago
Collaborator

I'm not going to argue about that. I still prefer to leave it out during the bootstrapping period, because lockfiles also have to be maintained, and include it once the project is mature.

We are talking about exactly 8.2KB 🙃

I'm not going to argue about that. I still prefer to leave it out during the bootstrapping period, because lockfiles also have to be maintained, and include it once the project is mature. We are talking about exactly 8.2KB 🙃
fnetX marked this conversation as resolved
SUSPICIOUS_USER_KEYWORDS = comma, separated, list
[repos]
QUARANTINE_OWNER = owner_which_holds_quarantine
fnetX commented 4 months ago
Collaborator

the changes to this file are minimal, why can't we instead use the existing example configuration? Feel free to adapt the placeholders to those you need for docker, as long as they still convey the same meaning.

the changes to this file are minimal, why can't we instead use the existing example configuration? Feel free to adapt the placeholders to those you need for docker, as long as they still convey the same meaning.
lil5 commented 4 months ago
Poster

This should be fixed, I've removed the duplicate moderation_backend.docker.ini

This should be fixed, I've removed the duplicate `moderation_backend.docker.ini`
fnetX marked this conversation as resolved
fnetX reviewed 4 months ago
DEVELOPMENT.md Outdated
# Development
This uses docker to keep things consistent across platforms and create an easier way to get started.
fnetX commented 4 months ago
Collaborator

Uh oh I think I found a Gitea bug - one of my comments weren't saved (I can't see it at least). Anyway, I wrote to this step that docker is definitely not necessary for most GNU/Linux users (and we won't support anything else). While you can run the app in docker if you prefer, I'd appreciate if you could separate the general steps from those specific to docker.

The non-docker part is make or make run after installing Go.

Uh oh I think I found a Gitea bug - one of my comments weren't saved (I can't see it at least). Anyway, I wrote to this step that docker is definitely not necessary for most GNU/Linux users (and we won't support anything else). While you *can* run the app in docker if you prefer, I'd appreciate if you could separate the general steps from those specific to docker. The non-docker part is `make` or `make run` after installing Go.
lil5 marked this conversation as resolved
Collaborator

@lil5 I read your comment via email. No, I don't object to docker in general, in fact I use it for most of my own server stuff. I don't mind adding a way to simply use docker if someone prefers, but I don't like telling users that it's "the" way, because for this project I honestly think it's even easier without, so I'd prefer to have it as an option, but not as "the" option 😉

@lil5 I read your comment via email. No, I don't object to docker in general, in fact I use it for most of my own server stuff. I don't mind adding a way to simply use docker if someone prefers, but I don't like telling users that it's "the" way, because for this project I honestly think it's even easier without, so I'd prefer to have it as an option, but not as "the" option 😉
lil5 added 1 commit 4 months ago
Collaborator

Small heads-up: I just pushed likely conflicting changes, but I included some of your changes in the default ini file. Since you don't (yet?) provide a simple mailer, I left the mail section untouched.

Small heads-up: I just pushed likely conflicting changes, but I included some of your changes in the default ini file. Since you don't (yet?) provide a simple mailer, I left the mail section untouched.
lil5 added 1 commit 4 months ago
lil5 added 1 commit 4 months ago
Poster

Since you are heavily using third-party dependencies, please either drop them or indicate that this guide is not audited or maintained by Codeberg but the community, and people should use everything outside the official instructions (= install go and do make) at their own risk.

I have changed the texts to note that it is unofficial.

> Since you are heavily using third-party dependencies, please either drop them or indicate that this guide is not audited or maintained by Codeberg but the community, and people should use everything outside the official instructions (= install go and do `make`) at their own risk. I have changed the texts to note that it is unofficial.
Collaborator

Thank you.

I'll probably try to adjust the development guide to something official soon and add some more notes from my side, or make the whole project more easy to newcomers anyway. Thank you for the start. Anything left, if not I'll merge this later today.

Thank you. I'll probably try to adjust the development guide to something official soon and add some more notes from my side, or make the whole project more easy to newcomers anyway. Thank you for the start. Anything left, if not I'll merge this later today.
fnetX approved these changes 4 months ago
fnetX referenced this issue from a commit 4 months ago
Collaborator

Hmm, manual merge detection is broken :-/

Anyway, I just merged it now. Thanks :)

Hmm, manual merge detection is broken :-/ Anyway, I just merged it now. Thanks :)
fnetX closed this pull request 4 months ago
fnetX added the
merged
label 4 months ago

Reviewers

fnetX approved these changes 4 months ago
This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Loading…
There is no content yet.