When customers start using GitHub Enterprise with Actions and private runners, there are some common gotcha’s you can run into. In this post I’m sharing the ones I have encountered so far. Even Dependabot comes along, since that runs on Actions as well for GitHub Enterprise Server.
List of topics:
Be aware that the default actions in the /actions organization (setup-node, setup-go, etc.), will download the binaries they need from github.com. This means the runner will download those files without any authentication and will be rate limited after 60 downloads/hour/ip-address. To get around that, you will need to create your own version of these actions and download the releases from something like GitHub Releases or an internal source like Artifactory, or store them as GitHub Releases in a repository.
This was not such a pleasant surprise: we have had to customize the default actions, since setup-node and setup-go will download the binaries from github.com (see above). Our runners do not have internet access for security reasons. We have created our own versions of these actions that download the binaries from our internal Artifactory instance and uploaded them to our GitHub Enterprise instance. This worked fine for a while, but when we upgraded from 3.1 to 3.2, the actions org was cleaned up and our custom actions were gone. This was not a problem for us, since we had copies of the source code on several machines, but it was a surprise. So be aware: the entire org gets cleaned up with each major/minor update!
There are 2 different idioms in the settings, and if you have admin rights (either Enterprise, Org or repo level), you will see both.
For the second one, here is an example. There is a save button in here, so…. what do you thing will happen if you change the
All repositories setting in the drop down?
This setting posts back to the server immediately, so the change is stored and in effect immediately! There is a small page reload, but if you are not paying attention, you could miss it. Guess how I turned off GitHub Actions for all users in our Production Environment? I took a bit more then half an hour before users started calling us (my team maintains it), and a check on this page to learn that the setting was changed…. That was not the intention, because I didn’t press the save button!
When you want to enable Dependabot, and it’s version updates, you need to do this at several levels: first enable it on the appliance. Then change the settings for the Organization level to allow it to be used.
Then you can configure it per repo:
Dependabot for Enterprise Server runs on actions and are visible from the ‘Actions’ tab for the repo. That way you can monitor their runs. If you enable all the features, then runs will be scheduled. Only until you actually go and check those runs, you’ll learn that it is using a ‘dependabot’ label to target the runner with. This is of course so that you can control where these runs happen, and how many runners can be bothered with these jobs. That way Dependabot runs will not just randomly start hogging all of your runners that are labeled with ‘self-hosted’. So, you do need to create runners with that label, before anything starts to happen.
Hint: checkout the
Dependabot Version updatesworkflow run logs, that magically will appear in the ‘actions’ tab!
Because there is no API for Dependabot to monitor it’s runs, or a way to see queued runs and alert on them if they are queued for more then 30 minutes (for example), there is no good way to learn about this until you start searching around.
Finding out about this happened because I went looking for the settings and found the stuck in queue workflow run. Looking at the workflow definition told me what I needed to know. This is quite a bit hidden in the docs: if you know where to find it, and dig through 4 different pages of information on enabling Dependabot, then eventually you find this reference to it, hidden under step 3. I made a suggestion to make it more clear you need to do this here (update: PR accepted!).
This definition pulls down the
setup-node from your actions organization on the server. If you overwrite them with something custom (as we had to do since our runners are not allowed to download things from the internet), these runs can easily fail (for us they did). I have not found a way to override this workflow file, so you need to make sure this works. We currently are working on setting things up for us, which is halting our adoption of Dependabot at the moment ☹️.
GitHub Actions on the SaaS version (github.com) has been created with running on Azure in mind. All of those logs are stored then on cloud storage. Currently Azure Blob storage and AWS S3 Storage is supported. If you cannot push the logs to one of those, there is a Min.io container setup that has the exact API surface of an S3 bucket that can be used, to layer that on top of you own storage solution. You will need to create and configure that storage to be used before you can continue.
To be able to use GitHub Actions, you need to have GitHub Connect enabled. This is a feature that allows you to connect your GitHub Enterprise Server instance to GitHub.com. This is needed to be able to use the GitHub Marketplace. I’m not really sure why this is the case, because the runners will use their own internet connection to download the actions from github.com. The only reason I see would be the UI in the workflow editor, that allows you to search the public marketplace for actions.
You really need to check the actions and vet them, since the security model is based on trust. Read more on the state of the GitHub Actions Marketplace here.