GitHub actions: Development best practices

[tony]

Throughout the day Friday I was testing with a fork of actions-common and action-baseline. I am spending a significant amount of time repeating tasks, it's tricky to QA and develop locally. This is mostly a fact of life with GitHub actions, but I'm wondering if anyone else has ideas.

My current workflow:

Setup (only once)

1. Fork the baseline action (e.g.https://github.com/zaproxy/action-baseline)

2. Fork the common library (e.g. https://github.com/zaproxy/actions-common)

3. Switch to a new branch in both projects

4. Switch common library to my org (e.g. @myorg/action-base) <- perhaps this can be skipped if gitref is used in the action?

5. Update baseline action to point to my library fork (either via git repo or ref)

To run the edit (every time, repeatedly):

1. Edit the common library

2. Publish to the common library fork on NPM (actions-common-scans)

3. Update baseline action to use the new common library so it gets the change

4. In my personal project's scanning job, update the ref to use my action

5. Push to my personal repo

6. Repeat

I am open to any way to make this process more streamlined:

- Vendorizing common library to baseline repo (copy-pasting the code into the action instead of using NPM to pull it via package)

- Pointing to common via git ref of my forked branch to avoid npm publising

- A tool like https://github.com/nektos/act to test github actions locally

- Anything else?

When it comes to contributing back, the other pain point is we don't have a github actions to test the integration of the common library with the actions (I guess the contributor would need a PR at the action as well that pulls to their own repo's fork using @<ref>).

Vendorizing(?):

Vendorizing the common library would make it so changes can be seen by PR'ing to the action (e.g. actions-{baseline,full-scan,api-scan}) directly. It removes a lot of steps. The other benefit is the action wouldn't be blocked for common library releases (or other actions that could be undergoing big changes) The tradeoff with vendorizing common library is it can fall out of sync as time goes by.

[tony]

As a tiny update, you can point an action like action-{baseline,full-scan,api-scan} to point to a fork of https://github.com/zaproxy/actions-common via https://gitpkg.vercel.app/.

yarn add 'https://gitpkg.now.sh/yourrepo/actions-common/packages/scans?your-branch-name'

npm install 'https://gitpkg.now.sh/yourrepo/actions-common/packages/scans?your-branch-name'