tubearchivist/tubearchivist-frontend
1
0
Fork 0
mirror of https://github.com/tubearchivist/tubearchivist-frontend.git synced 2024-11-04 19:30:13 +00:00
Code Issues Projects Releases Wiki Activity

add unstable tag for docker deploy

Browse Source
This commit is contained in:
simon 2021-12-17 16:57:10 +07:00
parent a500f9ec63
commit 816c68464b
No known key found for this signature in database
GPG Key ID: 2C15AA5E89985DD4
2 changed files with 30 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
CONTRIBUTING.md
View File

@ -20,7 +20,7 @@ I have learned the hard way, that working on a dockerized application outside of
This is my setup I have landed on, YMMV: This is my setup I have landed on, YMMV:
- Clone the repo, work on it with your favorite code editor in your local filesystem. *testing* branch is the where all the changes are happening, might be unstable and is WIP. - Clone the repo, work on it with your favorite code editor in your local filesystem. *testing* branch is the where all the changes are happening, might be unstable and is WIP.
- Then I have a VM on KVM hypervisor running standard Ubuntu Server LTS with docker installed. The VM keeps my projects separate and offers convenient snapshot functionality. The VM also offers ways to simulate lowend environments by limiting CPU cores and memory. But you could also just run docker on your host system. - Then I have a VM on KVM hypervisor running standard Ubuntu Server LTS with docker installed. The VM keeps my projects separate and offers convenient snapshot functionality. The VM also offers ways to simulate lowend environments by limiting CPU cores and memory. But you could also just run docker on your host system.
- The `Dockerfile` is structured in a way that the actual application code is in the last layer so rebuilding the image with only code changes utilizes the build cache for everything else and will take just 2-3 secs. - The `Dockerfile` is structured in a way that the actual application code is in the last layer so rebuilding the image with only code changes utilizes the build cache for everything else and will just take a few seconds.
- Take a look at the `deploy.sh` file. I have my local DNS resolve `tubearchivist.local` to the IP of the VM for convenience. To deploy the latest changes and rebuild the application to the testing VM run: - Take a look at the `deploy.sh` file. I have my local DNS resolve `tubearchivist.local` to the IP of the VM for convenience. To deploy the latest changes and rebuild the application to the testing VM run:
```bash ```bash
./deploy.sh test ./deploy.sh test
@ -44,7 +44,12 @@ To fix a bug or implement a feature, fork the repository and make all changes to
## Releases ## Releases
Everything on the master branch is what's in the latest release and is what you get in your container when you `pull` either the *:latest* tag or the newest named version. If you want to test the newest changes and improvements, clone the repository and build the docker container with the Dockerfile from the testing branch. There are three different docker tags:
- **latest**: As the name implies is the latest multiarch release for regular usage.
- **unstable**: Intermediate amd64 builds for quick testing and improved collaboration. Don't mix with a *latest* installation, for your testing environment only. This is untested and WIP and will have breaking changes between commits that might require a reset to resolve.
- **semantic versioning**: There will be a handful named version tags that will also have a matching release and tag on github.
If you want to see what's in your container, checkout the matching release tag. A merge to **master** usually means a *latest* or *unstable* release. If you want to preview changes in your testing environment, pull the *unstable* tag or clone the repository and build the docker container with the Dockerfile from the **testing** branch.
## Code formatting and linting ## Code formatting and linting

26
deploy.sh
View File

@ -3,7 +3,8 @@
# deploy all needed project files to different servers: # deploy all needed project files to different servers:
# test for local vm for testing # test for local vm for testing
# blackhole for local production # blackhole for local production
# docker to publish # unstable to publish intermediate releases
# docker to publish regular release
# create builder: # create builder:
# docker buildx create --name tubearchivist # docker buildx create --name tubearchivist
@ -51,7 +52,8 @@ function sync_test {
--exclude "db.sqlite3" \ --exclude "db.sqlite3" \
. -e ssh "$host":tubearchivist . -e ssh "$host":tubearchivist
rsync -r --progress --delete docker-compose.yml -e ssh "$host":docker # uncomment or copy your own docker-compose file
# rsync -r --progress --delete docker-compose.yml -e ssh "$host":docker
if [[ $1 = "amd64" ]]; then if [[ $1 = "amd64" ]]; then
platform="linux/amd64" platform="linux/amd64"
@ -100,6 +102,22 @@ function validate {
} }
# publish unstable tag to docker
function sync_unsable {
if [[ $(systemctl is-active docker) != 'active' ]]; then
echo "starting docker"
sudo systemctl start docker
fi
# start amd64 build
sudo docker buildx build \
--platform linux/amd64 \
-t bbilly1/tubearchivist:unstable --push .
}
function sync_docker { function sync_docker {
# check things # check things
@ -152,8 +170,10 @@ elif [[ $1 == "validate" ]]; then
validate "$2" validate "$2"
elif [[ $1 == "docker" ]]; then elif [[ $1 == "docker" ]]; then
sync_docker sync_docker
elif [[ $1 == "unstable" ]]; then
sync_unsable
else else
echo "valid options are: blackhole | test | validate | docker" echo "valid options are: blackhole | test | validate | docker | unstable"
fi fi