I’ve been home this week on Christmas vacation. But I’m looking into an issue which is work related and also related to my personal use of GitHub. I’m learning how to use GitHub’s self-hosted runners. To that end I’ve created a simple C# console app in my personal account at home, then I’ve gone through the steps to add a self-hosted runner to that repo. At work I will do this for one of our GH organizations. While I was installing the self-hosted runner on my Windows 11 machine, at one point it asked me if I wanted to install it as a Windows service. The default was No, which I went with. I figured that such a simple app, I won’t be running the build often. However, at work I believe this should be installed as a Windows service, since it will be used for several repos in the organization. The last two steps, which I’ve not done yet, is to run this command in the actions-runner folder: ./run.cmd. Then put this into the YAML for the repo’s workflow: runs-on: self-hosted.
I’m assuming that when I run the ./run.cmd command in the actions-runner folder, that I can stop it by doing a Control-C. Correct?
There’s one thing I am not clear on, concerning self-hosted runners. Are GH self-hosted runners meant to be used for the whole CI/CD pipeline? I had been thinking that, at work, we would create the artifacts in GitHub, but then use the self-hosted runner as a means of deploying the app in our network. Having gone through this exercise I’m not wondering if I’ve got the wrong idea about how self-hosted runners are meant to be used?
You can use them as only deploy targets, you can also use them to build your actual software. Up to your requirements which you choose. Cost could be a reason to choose one option or another for example.
Thank you, for that additional information! Its good to know that we could either use self-hosted runners for deployment only or both build and deploy. I’m sure that cost will play a BIG part of which direction we chose to go.
