melabidi/carmanagement
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

fix build 4
Build & Deploy / Build & Push Docker Image (push) Failing after 4s
Details
Build & Deploy / Deploy to VPS (push) Has been skipped
Details

Browse Source
This commit is contained in:
root
2026-07-04 14:05:16 -04:00
parent c74789f949
commit b5dfe66373
2 changed files with 29 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/DOCKER.md
+17 -8
View File
@@ -211,24 +211,33 @@ REGISTRY_USER=<registry-user>
REGISTRY_PASSWORD=<registry-password>
```
For the deploy job, add these GitLab CI variables as well:
For the deploy job, add these Gitea Actions secrets as well:
```text
VPS_IP=<server-ip-or-hostname>
VPS_USER=<ssh-user>
SSH_PRIVATE_KEY=<deployment-private-key>
VPS_SSH_KEY=<deployment-private-key>
```
`SSH_PRIVATE_KEY` must be an unencrypted private key that OpenSSH can read in a non-interactive job. The pipeline accepts any of these formats:
`VPS_SSH_KEY` must be an unencrypted private key that OpenSSH can read in a non-interactive job. The workflow also accepts `VPS_SSH_KEY_B64` when you prefer storing a base64-encoded private key as a single line.
- GitLab `File` variable containing the private key
- Standard multiline key pasted directly into the variable value
- Single-line key with literal `\n` newline escapes
- Base64-encoded private key stored as a single line
Supported private key formats:
- Standard multiline key pasted directly into `VPS_SSH_KEY`
- Single-line key with literal `\n` newline escapes in `VPS_SSH_KEY`
- Base64-encoded private key stored as a single line in `VPS_SSH_KEY_B64`
If your key is passphrase-protected, generate a dedicated deploy key without a passphrase for CI instead of reusing an interactive workstation key.
The production compose file reads `APP_IMAGE` and `APP_VERSION` for pull-based deploys. The GitLab deploy job injects those values automatically and now syncs the deployment assets to the VPS before running the server-side deploy script. Production no longer depends on `git pull` during release.
If SSH authentication fails after the workflow loads the key, compare the logged deploy key fingerprint with the key installed on the server:
```bash
ssh-keygen -lf ~/.ssh/authorized_keys
```
The matching public key must be present in `~/.ssh/authorized_keys` for the account named by `VPS_USER`.
The production compose file reads `APP_IMAGE` and `APP_VERSION` for pull-based deploys. The Gitea deploy job injects those values automatically and syncs the deployment assets to the VPS before running the server-side deploy script. Production no longer depends on `git pull` during release.
The CI pipeline publishes and deploys from the GitLab default branch (`$CI_DEFAULT_BRANCH`). If you change your release branch, update the repository default branch in GitLab instead of hard-coding branch names in `.gitlab-ci.yml`.