Please join us today for our first GitHub Actions community AMA with Staff Product Manager Chris Patterson. And don’t forget to preregister for a chance to get some cool swag!
See you soon, AG
PS: This topic will reopen at 1:55pm PST ahead of the AMA kick off!
Hi @chrispat, would you mind introducing yourself and sharing a bit of what your role is on the GitHub Actions team?
I am a Staff Product Manager and I work on GitHub Actions. I am responsible for the overall experience, config file format, extensibility model, and pretty much everything that isn’t specific to compute.
What is the benefit of using GitHub Actions for continuous integration (CI) over a third-party application like Travis CI?
The primary benefit most of our customers have expressed is simply having everything in one place. We also here from a lot of people they like the flexibility of the system and the wide variety of community actions to reuse.
Are there any prerequisites to be able to write actions? Do I need to learn a programming language?
We have a couple of different models for creating Actions. The primary one we focus on is using JavaScript because it works on all of our supported platforms. However, you can implement an Action as a Docker container or simply as a shell script but your platform coverage might be limited.
Have you seen any GitHub Action that works in a fun/creative way? Maybe even outside of what was considered the scope of GitHub Actions.
Sure we have seen a few actions for ordering pizza’s.
@juanpflores we were just chatting about this one, as well:
…which:
Change all the files in your repo to a picture of Nicholas Cage
Hi @chrispat, thanks for taking the time to answer some questions! I have a few questions/comments about runners. Are there any plans to introduce some more controls around how runners are used? For example:
I’ve noticed that for Windows installing go onto RUNNER_WORKSPACE is about 3x faster than installing to RUNNER_TOOL_CACHE. They are on the D: and C: drives respectively. actions/setup-go installs to RUNNER_TOOL_CACHE. Is there a technical reason for installing to the slower drive? The difference is significant (about 55 seconds vs 18 seconds).
Interesting question.
We currently do not have a fallback model for the runners as the labels are different and typically for self hosted runners there is some other special requirement. However, we are working on a bunch of features to make the GitHub hosted runners more flexible and powerful.
On the job scheduling, I can take that feedback to the team and talk through how we might do that. One of the things we try to optimize for today is making sure you don’t have the opposite problem where a fast job can’t start because you have a workflow with a very long job that has other jobs downstream.
The image contains some pre-populated versions of various tools in the cache so that is going to be on the C drive. The action simply works by either locating the version in the tool cache or downloading and placing a new one. For a persistent self-hosted runner this works great but for the hosted runners and we didn’t want to special case the code in the action.
I know you guys have gotten a lot of feedback on the lack of templating in GA. Composite actions helps a bit but GA is still in desperate need of some sort of templating. I also know it is on the roadmap. Can you give any more details on the status of templating and when we can realistically expect this feature to be released?
Thanks. So I should be safe to write an action that installs to RUNNER_WORKSPACE? I didn’t find any documentation for that particular variable, so I wasn’t sure if it is guaranteed to remain and if there is a chance of it getting cleared in future steps.