actions
/
burnett01-rsync-deployments
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Compare commits

merge into: actions:drinternet-rsync-merge
Branches Tags
actions:master
actions:drinternet-rsync-merge
actions:non-release/8.0.0
actions:release/7.0.1
actions:release/7.0.0
actions:release/6.0.0
actions:release/5.2.1
actions:release/5.3
actions:7.0.1
actions:7.0.0
actions:6.0.0
actions:5.2.2
actions:5.2.1
actions:5.2
actions:5.1
actions:5.0
actions:4.1
actions:4.0
actions:3.0
actions:2.0
actions:1.0
...
pull from: actions:master
Branches Tags
actions:drinternet-rsync-merge
actions:master
actions:non-release/8.0.0
actions:release/7.0.1
actions:release/7.0.0
actions:release/6.0.0
actions:release/5.2.1
actions:release/5.3
actions:7.0.1
actions:7.0.0
actions:6.0.0
actions:5.2.2
actions:5.2.1
actions:5.2
actions:5.1
actions:5.0
actions:4.1
actions:4.0
actions:3.0
actions:2.0
actions:1.0

No commits in common. "drinternet-rsync-merge" and "master" have entirely different histories.
drinternet ... master

16 changed files with 408 additions and 157 deletions
Show Stats Expand all files Collapse all files

6
.github/dependabot.yml vendored Normal file
View File

@ -0,0 +1,6 @@
version: 2
updates:
- package-ecosystem: docker
directory: /
schedule:
interval: monthly

76
CODE_OF_CONDUCT.md Normal file
View File

@ -0,0 +1,76 @@
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, sex characteristics, gender identity and expression,
level of experience, education, socio-economic status, nationality, personal
appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment
include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team via issues. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
[homepage]: https://www.contributor-covenant.org
For answers to common questions about this code of conduct, see
https://www.contributor-covenant.org/faq

1
CONTRIBUTING.md Normal file
View File

@ -0,0 +1 @@
Feel free to contribute to this project.

20
Dockerfile
View File

@ -1,16 +1,8 @@
FROM alpine:3.20.0 # drinternet/rsync@v1.4.4
MAINTAINER Dr Internet <internet@limelightgaming.net> FROM drinternet/rsync@sha256:15b2949838074bd93c49421c22380396a0cd53a322439e799ac87afcadcfe234
# Install RSync and Open SSH. # Copy entrypoint
RUN apk update && apk add --no-cache rsync openssh-client COPY entrypoint.sh /entrypoint.sh
RUN rm -rf /var/cache/apk/* RUN chmod +x /entrypoint.sh
# Prepare SSH dir. ENTRYPOINT ["/entrypoint.sh"]
RUN mkdir ~/.ssh
# Copy in our executables.
COPY agent-* hosts-* /bin/
RUN chmod +x /bin/agent-* /bin/hosts-*
# Prepare for known hosts.
RUN hosts-clear

3
LICENSE
View File

@ -1,6 +1,7 @@
MIT License MIT License
Copyright (c) 2020 Joshua Piper Copyright (c) 2019-2022 Contention
Copyright (c) 2019-2024 Burnett01
Permission is hereby granted, free of charge, to any person obtaining a copy Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal of this software and associated documentation files (the "Software"), to deal

323
README.md
View File

@ -1,93 +1,254 @@
# rsync docker image. # rsync deployments
A simple alpine based docker image for rsync and ssh deployments. This GitHub Action (amd64) deploys files in `GITHUB_WORKSPACE` to a remote folder via rsync over ssh.
## Using this image Use this action in a CD workflow which leaves deployable code in `GITHUB_WORKSPACE`.
This image has two primary uses. Firstly, as a deployment image for GitLab CI runs. Secondly, as a base image for other images.
### gitlab-ci.yml The base-image [drinternet/rsync](https://github.com/JoshPiper/rsync-docker/) of this action is very small and is based on Alpine 3.19.1 (no cache) which results in fast deployments.
```yml
image: drinternet/rsync:1.0.1 ---
...
before_script: ## Inputs
- source agent-autostart "$CI_PROJECT_ID-$CI_PIPELINE_ID-$_CI_CONCURRENT_ID"
- hosts-add "$SSH_KNOWN_HOSTS" - `switches`* - The first is for any initial/required rsync flags, eg: `-avzr --delete`
- `rsh` - Remote shell commands
- `legacy_allow_rsa_hostkeys` - Enables support for legacy RSA host keys on OpenSSH 8.8+. ("true" / "false")
- `path` - The source path. Defaults to GITHUB_WORKSPACE and is relative to it
- `remote_path`* - The deployment target path
- `remote_host`* - The remote host
- `remote_port` - The remote port. Defaults to 22
- `remote_user`* - The remote user
- `remote_key`* - The remote ssh key
- `remote_key_pass` - The remote ssh key passphrase (if any)
``* = Required``
## Required secret(s)
This action needs secret variables for the ssh private key of your key pair. The public key part should be added to the authorized_keys file on the server that receives the deployment. The secret variable should be set in the Github secrets section of your org/repo and then referenced as the `remote_key` input.
> Always use secrets when dealing with sensitive inputs!
For simplicity, we are using `DEPLOY_*` as the secret variables throughout the examples.
## Current Version: 7.0.1
## Example usage
Simple:
after_script:
- agent-stop "$CI_PROJECT_ID-$CI_PIPELINE_ID-$_CI_CONCURRENT_ID"
``` ```
name: DEPLOY
on:
push:
branches:
- master
### Base image in a `Dockerfile jobs:
```dockerfile
FROM drinternet/rsync:1.0.1
COPY some/file or/whatever
```
## Inbuilt commands.
This base image also includes a few shell scripts, to help with managing SSH agents and known hosts files.
### SSH Agent Management
#### agent-start
This command starts the SSH agent, if it isn't already started (SSH_AGENT_PID set or ssh agent ID file found).
It takes one optional argument, for the name of the agent to be started. Defaults to "default".
This program needs to be source'd to work correctly.
`source agent-start "default"`
#### agent-stop
This command stops the SSH agent, if it is started (SSH_AGENT_PID set or ssh agent ID file found).
It takes one optional argument, for the name of the agent to be stopped. Defaults to "default".
`agent-stop "my-agent-name"`
#### agent-add
This command adds a key to the currently running SSH agent. The key is taken from stdin, and the agent used is that in SSH_AGENT_PID.
#### agent-autostart
This command starts the SSH agent and loads the private key from the "SSH_PRIVATE_KEY" environment var. The command takes one optional argument, for the name of the agent to be started. Defaults to "default".
As with agent-start, this command needs to be sourced.
#### agent-askpass
This command is called by ssh-add when the [SSH_ASKPASS](https://man.openbsd.org/ssh-add.1#ENVIRONMENT) variable is set active. The command returns the SSH_PASS to [ssh-askpass(1)](https://man.openbsd.org/ssh-askpass.1).
This command is ignored by ssh-add if the key does not require a passphrase.
### known_hosts management
#### hosts-clear
This command truncates the known_hosts file and sets its permissions.
#### hosts-add
This command adds an entry to the known hosts file, and ensures its permissions are correct. It takes one argument, which is the new key to add.
## Tags
Both the repository and Docker Hub images follow the [semantic versioning](https://semver.org/) standard.
Docker Hub image versions are prefixed with v, and contain the full version, version sub patch number and version sub minor and patch.
For example, the repository tag 1.2.3, creates the Hub tags v1.2.3, v1.2 and v1, to allow for binding to a specific version, specific minor version or specific major version.
## Example gitlab-ci.yml
```yml
image: drinternet/rsync:1.0.1
stages:
- deploy
before_script:
- source agent-autostart "$CI_PROJECT_ID-$CI_PIPELINE_ID-$_CI_CONCURRENT_ID"
- hosts-add "$SSH_KNOWN_HOSTS"
after_script:
- agent-stop "$CI_PROJECT_ID-$CI_PIPELINE_ID-$_CI_CONCURRENT_ID"
deploy: deploy:
stage: deploy runs-on: ubuntu-latest
script: steps:
- rsync -zrSlhaO --chmod=D2775,F664 --delete-after . $FTP_USER@$FTP_HOST:/var/www/deployment/ - uses: actions/checkout@v3
- name: rsync deployments
uses: burnett01/rsync-deployments@7.0.1
with:
switches: -avzr --delete
path: src/
remote_path: /var/www/html/
remote_host: example.com
remote_user: debian
remote_key: ${{ secrets.DEPLOY_KEY }}
``` ```
## Using with passphrase protected key Advanced:
You can supply a passphrase with ``SSH_PASS`` to ``agent-add``, ``agent-start`` or ``agent-autostart``.
``` ```
SSH_PASS="THE_PASSPHRASE" agent-add jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: rsync deployments
uses: burnett01/rsync-deployments@7.0.1
with:
switches: -avzr --delete --exclude="" --include="" --filter=""
path: src/
remote_path: /var/www/html/
remote_host: example.com
remote_port: 5555
remote_user: debian
remote_key: ${{ secrets.DEPLOY_KEY }}
``` ```
For better **security**, I suggest you create additional secrets for remote_host, remote_port, remote_user and remote_path inputs.
```
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: rsync deployments
uses: burnett01/rsync-deployments@7.0.1
with:
switches: -avzr --delete
path: src/
remote_path: ${{ secrets.DEPLOY_PATH }}
remote_host: ${{ secrets.DEPLOY_HOST }}
remote_port: ${{ secrets.DEPLOY_PORT }}
remote_user: ${{ secrets.DEPLOY_USER }}
remote_key: ${{ secrets.DEPLOY_KEY }}
```
If your private key is passphrase protected you should use:
```
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: rsync deployments
uses: burnett01/rsync-deployments@7.0.1
with:
switches: -avzr --delete
path: src/
remote_path: ${{ secrets.DEPLOY_PATH }}
remote_host: ${{ secrets.DEPLOY_HOST }}
remote_port: ${{ secrets.DEPLOY_PORT }}
remote_user: ${{ secrets.DEPLOY_USER }}
remote_key: ${{ secrets.DEPLOY_KEY }}
remote_key_pass: ${{ secrets.DEPLOY_KEY_PASS }}
```
---
#### Legacy RSA Hostkeys support for OpenSSH Servers >= 8.8+
If your remote OpenSSH Server still uses RSA hostkeys, then you have to
manually enable legacy support for this by using ``legacy_allow_rsa_hostkeys: "true"``.
```
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: rsync deployments
uses: burnett01/rsync-deployments@7.0.1
with:
switches: -avzr --delete
legacy_allow_rsa_hostkeys: "true"
path: src/
remote_path: ${{ secrets.DEPLOY_PATH }}
remote_host: ${{ secrets.DEPLOY_HOST }}
remote_port: ${{ secrets.DEPLOY_PORT }}
remote_user: ${{ secrets.DEPLOY_USER }}
remote_key: ${{ secrets.DEPLOY_KEY }}
```
See [#49](https://github.com/Burnett01/rsync-deployments/issues/49) and [#24](https://github.com/Burnett01/rsync-deployments/issues/24) for more information.
---
## Version 6.0 (MAINTENANCE)
Check here:
- https://github.com/Burnett01/rsync-deployments/tree/6.0 (alpine 3.17.2)
---
## Version 5.0, 5.1 & 5.2 & 5.x (DEPRECATED)
Check here:
- https://github.com/Burnett01/rsync-deployments/tree/5.0 (alpine 3.11.x)
- https://github.com/Burnett01/rsync-deployments/tree/5.1 (alpine 3.14.1)
- https://github.com/Burnett01/rsync-deployments/tree/5.2 (alpine 3.15.0)
- https://github.com/Burnett01/rsync-deployments/tree/5.2.1 (alpine 3.16.1)
- https://github.com/Burnett01/rsync-deployments/tree/5.2.2 (alpine 3.17.2)
---
## Version 4.0 & 4.1 (EOL)
Check here:
- https://github.com/Burnett01/rsync-deployments/tree/4.0
- https://github.com/Burnett01/rsync-deployments/tree/4.1
Version 4.0 & 4.1 use the ``drinternet/rsync:1.0.1`` base-image.
---
## Version 3.0 (EOL)
Check here: https://github.com/Burnett01/rsync-deployments/tree/3.0
Version 3.0 uses the ``alpine:latest`` base-image directly.<br>
Consider upgrading to 4.0 that uses a docker-image ``drinternet/rsync:1.0.1`` that is<br>
based on ``alpine:latest``and heavily optimized for rsync.
## Version 2.0 (EOL)
Check here: https://github.com/Burnett01/rsync-deployments/tree/2.0
Version 2.0 uses a larger base-image (``ubuntu:latest``).<br>
Consider upgrading to 3.0 for even faster deployments.
## Version 1.0 (EOL)
Check here: https://github.com/Burnett01/rsync-deployments/tree/1.0
Please note that version 1.0 has reached end of life state.
---
## Acknowledgements
+ This project is a fork of [Contention/rsync-deployments](https://github.com/Contention/rsync-deployments)
+ Base image [JoshPiper/rsync-docker](https://github.com/JoshPiper/rsync-docker)
---
## Media
This action was featured in multiple blogs across the globe:
> Disclaimer: The author & co-authors are not responsible for the content of the site-links below.
- https://leobrack.co.uk/blog/2020-02-15-automatically-push-changes-to-your-live-site-with-github-actions
- https://blog.maniak.co/ci-cd-for-wordpress/
- https://elijahverdoorn.com/2020/04/14/automating-deployment-with-github-actions/
- https://www.vektor-inc.co.jp/post/github-actions-deploy/
- https://ews.ink/tech/blog-deploy-2/
- https://webpick.info/automatiser-avec-github-actions/
- https://matthias-andrasch.eu/blog/2021/tutorial-webseite-mittels-github-actions-deployment-zu-uberspace-uebertragen-rsync/
- https://mikael.koutero.me/posts/hugo-github-actions-deploy-rsync/
- https://cdmana.com/2021/02/20210208122400688I.html
- https://jishuin.proginn.com/p/763bfbd38928
- https://cloud.tencent.com/developer/article/1786522
- http://www.ningco.cn/github_action_deploy_blog/
- https://qdmana.com/2021/01/20210127094413405u.html

19
SECURITY.md Normal file
View File

@ -0,0 +1,19 @@
# Security Policy
## Supported Versions
The following versions are currently being supported with security updates:
| Version | Supported |
| ------- | ------------------ |
| 7.x | :white_check_mark: |
| 6.x | :information_source: MAINTENANCE |
| 5.x | :warning: DEPRECATED |
| 4.x | :x: EOL |
| 3.0 | :x: EOL |
| 2.0 | :x: EOL |
| 1.0 | :x: EOL |
## Reporting a Vulnerability
You can report a vulnerability by creating an issue.

45
action.yml Normal file
View File

@ -0,0 +1,45 @@
name: 'Rsync Deployments Action'
description: 'GitHub Action for deploying code via rsync over ssh'
author: 'Burnett01'
inputs:
switches:
description: 'The switches'
required: true
rsh:
description: 'The remote shell argument'
required: false
default: ''
legacy_allow_rsa_hostkeys:
description: 'Enables support for legacy RSA host keys on OpenSSH 8.8+'
required: false
default: 'false'
path:
description: 'The local path'
required: false
default: ''
remote_path:
description: 'The remote path'
required: true
remote_host:
description: 'The remote host'
required: true
remote_port:
description: 'The remote port'
required: false
default: 22
remote_user:
description: 'The remote user'
required: true
remote_key:
description: 'The remote key'
required: true
remote_key_pass:
description: 'The remote key passphrase'
required: false
default: ''
runs:
using: 'docker'
image: 'Dockerfile'
branding:
icon: 'send'
color: 'gray-dark'

4
agent-add
View File

@ -1,4 +0,0 @@
#!/bin/sh
source agent-start "${1:-default}"
cat - | tr -d '\r' | DISPLAY=1 SSH_ASKPASS=agent-askpass ssh-add - >/dev/null

2
agent-askpass
View File

@ -1,2 +0,0 @@
#!/bin/sh
echo "$SSH_PASS"

4
agent-autostart
View File

@ -1,4 +0,0 @@
#!/bin/sh
source agent-start "${1:-default}"
echo "$SSH_PRIVATE_KEY" | agent-add

22
agent-start
View File

@ -1,22 +0,0 @@
#!/bin/sh
FOLDER=${1:-default}
STORE_PATH="/tmp/ssh-agent/$FOLDER"
mkdir -p "$STORE_PATH"
# Start the SSH agent if it isn't already.
if [ -z "$SSH_AGENT_PID" ]; then
if [ -f "$STORE_PATH/id" ]; then
# Our auth agent is already running.
# Reload the vars, and export them.
SSH_AGENT_PID=$(cat "$STORE_PATH/id")
export SSH_AGENT_PID
SSH_AUTH_SOCK=$(cat "$STORE_PATH/sock")
export SSH_AUTH_SOCK
else
eval "$(ssh-agent)" > /dev/null
echo "$SSH_AGENT_PID" > "$STORE_PATH"/id
echo "$SSH_AUTH_SOCK" > "$STORE_PATH"/sock
fi
fi

35
agent-stop
View File

@ -1,35 +0,0 @@
#!/bin/sh
if [ ! -z "$SSH_AGENT_PID" ]; then
# Here, the environment is set already, just kill the script.
eval $(ssh-agent -k) >/dev/null
exit $?
else
# The env isn't set, construct the file path.
FOLDER=${1:-default}
STORE_PATH="/tmp/ssh-agent/$FOLDER"
if [ ! -d "$STORE_PATH" ]; then
echo "Store Path $STORE_PATH doesn't exist!" >&2
exit 1
fi
# And check our files exist.
if [ -f "$STORE_PATH/id" ]; then
# Grab our PID and socket.
SSH_AGENT_PID=$(cat "$STORE_PATH/id")
export SSH_AGENT_PID
rm "$STORE_PATH/id"
SSH_AUTH_SOCK=$(cat "$STORE_PATH/sock")
export SSH_AUTH_SOCK
rm "$STORE_PATH/sock"
rmdir "$STORE_PATH"
eval $(ssh-agent -k) >/dev/null
exit $?
else
echo "SSH_AGENT_PID not set, $STORE_PATH/id doesn't exist!" >&2
exit 1
fi
fi

25
entrypoint.sh Executable file
View File

@ -0,0 +1,25 @@
#!/bin/sh
if [ -z "$(echo "$INPUT_REMOTE_PATH" | awk '{$1=$1};1')" ]; then
echo "The remote_path can not be empty. see: github.com/Burnett01/rsync-deployments/issues/44"
exit 1
fi
# Start the SSH agent and load key.
source agent-start "$GITHUB_ACTION"
echo "$INPUT_REMOTE_KEY" | SSH_PASS="$INPUT_REMOTE_KEY_PASS" agent-add
# Add strict errors.
set -eu
# Variables.
LEGACY_RSA_HOSTKEYS="-o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa"
LEGACY_RSA_HOSTKEYS=$([ "$INPUT_LEGACY_ALLOW_RSA_HOSTKEYS" = "true" ] && echo "$LEGACY_RSA_HOSTKEYS" || echo "")
SWITCHES="$INPUT_SWITCHES"
RSH="ssh -o StrictHostKeyChecking=no $LEGACY_RSA_HOSTKEYS -p $INPUT_REMOTE_PORT $INPUT_RSH"
LOCAL_PATH="$GITHUB_WORKSPACE/$INPUT_PATH"
DSN="$INPUT_REMOTE_USER@$INPUT_REMOTE_HOST"
# Deploy.
sh -c "rsync $SWITCHES -e '$RSH' $LOCAL_PATH $DSN:$INPUT_REMOTE_PATH"

4
hosts-add
View File

@ -1,4 +0,0 @@
#!/bin/sh
echo "$@" >> ~/.ssh/known_hosts
chmod 0664 ~/.ssh/known_hosts

4
hosts-clear
View File

@ -1,4 +0,0 @@
#!/bin/sh
truncate -s 0 ~/.ssh/known_hosts
chmod 0664 ~/.ssh/known_hosts