Question: config.json (and two other questions)
Closed this issue · 5 comments
I would have rather opened a discussion, but it's not enabled on this repo.
In regards to your config.json
, the docs are rather limited. Is this config.json file something that we must edit in the source and then re-build the docker image with our own custom packages?
Or is this a file we can drop in the container's mounted volume and it will be picked up. Because at present, I don't see it in there.
Or is this another volume we must mount.
I guess another question so I don't have to bug later if I can't find it. Currently, the worker shuts down after a job is done. What is the correct way to handle this situation so that the worker stays up, or is the shut down by design choice. To combat this, should I:
- Set
restart: always
on the worker - A particular setting I'm missing that removes this functionality?
- Should a system service be created to detect it being down
I don't see any errors in the console as if the worker crashed, so I assume it's by design. All I see is:
2024-10-23 14:44:18Z: Job build completed with result: Succeeded
√ Removed .credentials
√ Removed .runner
Third question and final: You have the property REPO_NAME
, but I'm not seeing if we have the option to allow the same worker to be used on multiple repos. Not sure if just removing the property all together allows for such a thing. However, Github gives a token for each worker which is different between each repo, so I don't see how that would work. I currently don't have my repos in an organization, as it would change their URLs, so I opted against that. They are on a single user.
Information for it is in the wiki, anything missing can be added
I'm unsure about the restart per job, that doesn't seem accurate from my usage
You'd run a worker per repo with that environment variable set
Information for it is in the wiki, anything missing can be added
The only part of this question I semi can see is:
Customizing the Image
The runner image can be customized by modifying the config.json file.
The only other part that may semi hint at it would be:
Sources:
For apt-sourced packages, any package can be installed for the sources configured in sources.sh.
For script-sourced packages, a function must exist in tools.sh with the name install_.
But it doesn't really give anymore than that. Not if the config.json can be auto-detected, or if the config is only good for a re-build of the image, and then all parameters are static throughout the life of that re-build. To add more packages, one would need to re-build again.
I even did a search through your code for the file, and the only place I found it after my post, was in the build.sh
, so I'm going to assume, shy of the docs saying so, that the image must be re-built each time a package needs to be added.
I'm unsure about the restart per job, that doesn't seem accurate from my usage
Shouldn't be anything special about my setup, but I'll have to investigate more. For now, I've just set the container to always restart if something happens, and that has kept it up. Yet if I run the github runner on a bare metal setup, it just runs each job as it gets it. Haven't had the time as I'm busy with other projects, so I'll have to investigate that one more, or read through the code.
Yes indeed, you'll need to rebuild the image for anything in the config.json
to take affect. It's useful particularly for stripping things out if you want a leaner image as I do. You can obviously also use the base or runner image as a parent image and do your own thing to install things on top.
Appreciate the info.
So just to clarify to make sure I understand:
You'd run a worker per repo with that environment variable set
Which means unless I have an organization, I have to create an individual worker per repo, and cannot share the worker. Each one should have my individual repo url, and then my access token.
I assume however, if I created an Organization, then I could share the workers between repos. Only issue with that is the URL changing. Otherwise I would.
Org runners pick up from any repo under an org
If you want to change that behavior you can use runner groups if you're on a paid GitHub team plan or higher afaik: https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/managing-access-to-self-hosted-runners-using-groups
I'm gonna close this as completed as all the questions related to my project are answered