We can implement CI workflow using GitHub's runner and SSH into our server to deploy. However, because of our extra-tier IP restricted firewall. We cannot use GitHub runner as it have has the same IP address ranges as Azure Data centers. Furthermore, SSH is not possible unless we request Media3 to turn off DUO authentication for the server web user account. I created a workflow using GitHub Action with our own self-hosted runner (which is installed under my superuser, the web user does not have enough privilege to install and run the runner ) and execute sudo command as the web user account.
Adding a self-hosted runner to a repository or an
organizationorganization
I added our dev server to the organization as many repositories uses the dev server. For prod server that only related to one repo (such as SPI), it's better to install to a repository.
You can add self-hosted runners at the organization level, where they can be used to process jobs for multiple repositories in an organization. To add a self-hosted runner to an organization, you must be an organization owner.
...
On GitHub, navigate to the main page of the organization.
...
Under your organization name, click Settings.
...
In the left sidebar, click Actions.
...
Under "Self-hosted runners," click Add new, then click New runner.
...
Select the operating system and architecture of your self-hosted runner machine.
You will see instructions showing you how to download the runner application and install it on your self-hosted runner machine.
Open a shell on your self-hosted runner machine and run each shell command in the order shown.
Note: On Windows, if you want to install the self-hosted runner application as a service, you must open a shell with administrator privileges. We also recommend that you use C:\actions-runner
as the directory for the self-hosted runner application so that Windows system accounts can access the runner directory.
The instructions walk you through completing these tasks:
...
- On Windows, the
config
script also asks if you would like to install the self-hosted runner application as a service. For Linux and macOS, you can install a service after you finish adding the runner. For more information, see "Configuring the self-hosted runner application as a service."
Set up SSH Key for GitHub to skip password at each git command
Workflow syntax
sample workflow syntax for deploy to dev and prod.
How to run SSH commands
We probably won't use this approach because of the IP restriction firewall. I put down my research in case it's useful in the future.
...
Configureing as a Service
...
- Stop the self-hosted runner application if it is currently running.
Install the service
Start the service
Check the status of the service
Code Block | ||
---|---|---|
| ||
sudo ./svc.sh stop
sudo ./svc.sh install
sudo ./svc.sh start
sudo ./svc.sh status |
Checking that your self-hosted runner was successfully added
After completing the steps to add a self-hosted runner, the runner and its status are now listed under "Self-hosted runners".
The self-hosted runner application must be active for the runner to accept jobs. When the runner application is connected to GitHub and ready to receive jobs, you will see the following message on machine's terminal.
√ Connected to GitHub
2019-10-24 05:45:56Z: Listening for Jobs
For more information, see "Monitoring and troubleshooting self-hosted runners."
Checking the status of a self-hosted runner
Related articles
Adding a self-hosted runner to a repository
Adding a self-hosted runner to an organization
How to use GitHub Actions with your own self-hosted runner (aka build agent)
Configuring the self-hosted runner application as a service
Monitoring and troubleshooting self-hosted runners
Code Block | ||
---|---|---|
| ||
|
...