Request GitHub Actions to be added to the internal marketplace

In my previous post I showed you how to setup an internal marketplace for GitHub Actions to help you users find actions when you follow the best practices and fork all the actions you use (and limit the use to only those forks!).

This post is the follow up on that: now that we have an internal marketplace, how can we give users a process to follow to request actions to be added to it? We started a workflow called github-actions-requests for that!

My Workflow

We have multiple workflows that do the work, so let's go over the steps in our process:

1. User follows the issue template to request an action to be reviewed for the marketplace.
2. An engineer with a security mindset reviews the source of the action (it's open source, so check the code!) for big issues, like sending out your data into the web for example. If nothing found, the engineer labels the issue with 'security-check'.
3. The issue-labeled-as-security-scan.yml workflow is triggered and runs all the security checks. The results are posted back to the request issue.
4. We fork the action repository and enable dependabot to run it's software composition analysis so we can retrieve any vulnerability alerts. Unfortunately we cannot retrieve information about dependabot's last run or if it is currently running. We have to wait for that.
5. After waiting sometime (can be minutes, can be longer). The engineer labels the issue with 'load-dependabot-alerts'.
6. The workflow dependabot-alerts.yml is triggered and fetches all vulnerability alerts from the forked action. It then posts back the findings into the request issue.
7. After a final check, the label final-signoff is used to sign off. The final-signoff.yml workflow is triggered and forks the action repository to its final destination: the organization that is used in production for storing all your used actions.

Workflow view:

The workflow has a couple of parallel jobs that give the UI renderer some issues 😎

If you want to know more, check out this video on it:

Submission Category:

• Maintainer Must-Haves

Yaml File or Link to Code

We use multiple workflows for this, but it starts with issue-labeled-as-security-scan workflow

Additional Resources / Info

Could not have done this without the help of Hindrik Bruinsma! We have lots of interest from the community in this process, with lots of ideas on how to improve!

Comments

[Mark Phippard]

Do you typically do any modifications to your forks? For example, I am used to reading the documentation for an action which almost always includes copy and pasting the snippet to get started. Since the forked version lives in a different location do you update the documentation so that the snippets still work?

Do you also adjust the workflow files that build the action so that you are building your own version and can update the Docker container etc to latest fixes?

[Rob Bos]

I normally don't, but I am on the fence of that. Biggest issue comes from using containers or downloading binaries on the fly: those adjustments will have to be made.

If you do: then updating the forks will become very hard. Sending back updates will be hard as well.
If you don't: then it is a (small) hurdle for your internal developers. Internal containers is the next issue indeed. I'm not sure on the solution yet.

Even mirroring the actions internally will have the same issue: will you tell your users to use a custom branch with the changes, that you then need to keep up to date?

I would really like if the internal container registry can be placed in front of your internal runners transparently, fixing the issue that way.

We're currently starting a larger rollout with this, and we need to onboard 60+ actions in one go. Will add the learnings from that process when they show up ;-).

[Mark Phippard]

Thanks, we have been debating this as we are about to roll out something similar. It feels to me like it will be a nuisance for the user to have the docs they copy and paste not work ... but I also think anyone authoring a workflow ought to be able to figure this out. It will be good to hear your experience on that if you have users using this.

[Rob Bos]

I intent to show the correct example in the internal marketplace as well, since we can just overwrite what we show there. If the user then goes to the forked repo, they'll still see the original README.md of course.