Docs: Add docker-compose.yml example and use binary as entrypoint in readme `docker run` examples

[leojonathanoh]

Adds example documentation, so that newer users know the best practices of how to run servers using docker run or docker-compose.

By using the server binary as the entrypoint, there is no more reliance on the image's in-built ENTRYPOINT [ "bin/bash", "-c" ] as a convenience feature that makes CMD's first argument PID 1.

$ docker-compose up
Creating network "docker-sourceservers_default" with the default driver
Creating docker-sourceservers_csgo_1 ... 
Creating docker-sourceservers_cstrike_1 ... 

$ docker attach docker-sourceservers_csgo_1 
MasterRequestRestart
Your server needs to be restarted in order to receive the latest update.
status
hostname: Counter-Strike: Global Offensive
version : 1.37.7.0/13770 1185/8012 secure  [A:1:1434222592:18370] 
udp/ip  : 192.168.176.3:27015  (public ip: 112.199.150.125)
os      :  Linux
type    :  community dedicated
map     : de_dust2
players : 0 humans, 0 bots (10/0 max) (hibernating)

# userid name uniqueid connected ping loss state rate adr

$ docker attach docker-sourceservers_cstrike_1 
status
hostname:  Counter-Strike 1.6 Server
version :  48/1.1.2.7/Stdio 7882 secure  (10)
tcp/ip  :  192.168.176.2:27016
map     :  de_dust2 at: 0 x, 0 y, 0 z
players :  0 active (10 max)

#      name userid uniqueid frag time ping loss adr
0 users
exit

Related: #1, #3, #22

@joeltimothyoh

[leojonathanoh]

EDIT: moved to OP

[leojonathanoh]

@joeltimothyoh added docs under ENTRYPOINT and CMD section

[joeltimothyoh]

I'm thinking I would prefer if PR source branches were from forked repositories. Reason being that this repo is OSS and that all contributors are part of the same community. But with said workflow source branches would not be stored within this repository and can be removed from forked repos. Yet it wouldn't matter if squash commits are used as all changes within PRs will be condensed into a single commit independent of source branches. Thoughts @leojonathanoh

Also CircleCI never used to offer a way of limiting of CI jobs to certain branches. As such pushes to branches within this repo would trigger creation of pipeline jobs which contaminates CI log histories and CI notification histories. Perhaps there's a way to limit so now. Yet this is another legitimate reason for source branches being from forked repos.

[leojonathanoh]

I'm thinking I would prefer if PR source branches were from forked repositories. Reason being that this repo is OSS and that all contributors are part of the same community. But with said workflow source branches would not be stored within this repository and can be removed from forked repos. Yet it wouldn't matter if squash commits are used as all changes within PRs will be condensed into a single commit independent of source branches. Thoughts @leojonathanoh

To me, it really doesn't matter how many branches there are in a git repo. That's how it's meant to be used. It also provides better traceability if branches are kept.

Also CircleCI never used to offer a way of limiting of CI jobs to certain branches. As such pushes to branches within this repo would trigger creation of pipeline jobs which contaminates CI log histories and CI notification histories. Perhaps there's a way to limit so now. Yet this is another legitimate reason for source branches being from forked repos.

it should be no different whether the PR was initiated by a fork or on the very repo itself. The pipeline created is a PR pipeline.

[joeltimothyoh]

To me, it really doesn't matter how many branches there are in a git repo. That's how it's meant to be used. It also provides better traceability if branches are kept.

Thing is this repo is designed to be pipeline based rather than branch based and so does not follow the conventional use of branches.

it should be no different whether the PR was initiated by a fork or on the very repo itself. The pipeline created is a PR pipeline.

It matters though with CircleCI. You would see from the CI job logs and notification histories that only PRs of this pipeline triggered lots of failed jobs from creation of the source branch and subsequent force-pushes, but which isn't the case for PRs where source branches are from forked repositories. @leojonathanoh

[leojonathanoh]

Thing is this repo is designed to be pipeline based rather than branch based and so does not follow the conventional use of branches.

true. these CI configs really have limitations. At least github workflows can limit pipeline to branch names. If it be, and github runners have more space now, it's just be better to move from all of those CIs.

It matters though with CircleCI. You would see from the CI job logs and notification histories that only PRs of this pipeline triggered lots of failed jobs from creation of the source branch and subsequent force-pushes, but which isn't the case for PRs where source branches are from forked repositories. @leojonathanoh

yes. it's a problem with circleci's config that does not allow limiting pipelines to certain branch names. it's better to move on if there's a better ci.

[joeltimothyoh]

true. these CI configs really have limitations. At least github workflows can limit pipeline to branch names. If it be, and github runners have more space now, it's just be better to move from all of those CIs.

Possible to move except for storage space on GHA makes it impossible to build the larger games on it.

[leojonathanoh]

GHA 37GB available. just a little too small https://github.com/theohbrothers/docker-ansible/runs/3612854410?check_suite_focus=true#step:3:72

[joeltimothyoh]

GHA 37GB available. just a little too small https://github.com/theohbrothers/docker-ansible/runs/3612854410?check_suite_focus=true#step:3:72

Yes, and without log retention. Not an option @leojonathanoh

[leojonathanoh]

let me reopen a PR from my fork

[leojonathanoh]

Closing in favor of #26