The starting point of a JS Action is just writing a Node program. Compared to other serverless function tools, these programs can do whatever and can run side effects while traditional FaaS are request / response driven. Then, write the following in your
# ...runs:using: "node12"main: "index.js"# ...
node12 tells you that the runtime is going to be Node.
main is the entrypoint for your node app.
Then you can point the workflow file to use it.
If it is in the same repo as your other code you wish, you can use as follows:
steps:- name: Actionuses: ./path/to/action
or in another repo:
steps:- name: Actionuses: lannonbr/My-Cool-Action
The Actions team wrote an Actions Toolkit that can be used with JS Actions. It can handle functionality such as I/O, getting inputs and setting outputs, connecting to the GitHub API, caching data, and many others.
Gotcha: node modules aren't installed automatically
Do note, when working with a JS Action, it will not download node modules for you automatically. To deal with this, you have two choices:
download them in the runner. you can run
npm installto grab the various modules, but then you have to dive into the details of the Action which breaks a layer of abstraction around Actions. even if you can view the code of an Action, it is a self-contained thing and with such with a strong API, you should not care about the internal details other than what it may be able to take in, what it can return, and what other side effects.
bundle it up. using a tool like Webpack, all of the required code can be bundled up into a "fat blob" that is stored up in Git. Even if the file becomes in the MBs in size, the only code bundled should be the code needed. then a consumer of said action doesn't need to worry about the modules that the action requires internally and can just run it. This keeps the contract between the Action author and consumer.