Actions workflows to help organizations manage the process of users requesting to use GitHub Actions from Marketplace and approving or denying such requests within an organization.
OTHER License
In GitHub Enterprise Server you can allow access to marketplace actions by configuring GitHub Connect. However, controlling which actions can be used comes at a huge administrative cost, as you would need to configure each org to allow the actions you approve of. Sometimes org admins are not the appropriate people to decide what actions are allowed or not. You may want to control allowed action for the entire enterprise, which can be done through the Enterprise Settings>Policies>Actions. However, there is no API to automate updating this setting, and there is no way to stage actions and allow admins to evaluate them before approval for wider use within your enterprise. The same issue exists for managing access to marketplace actions in GitHub Enterprise Cloud. In these cases, you want to host the requested marketplace actions in an org within your enterprise as private repos, allowing admins to evaluate the actions prior to making them available within your enterprise. Upon approval, the visibility of the repo changes so that the action is available to users within your enterprise.
This project provides two actions workflows to help manage the process of requesting marketplace actions and approving or denying such requests: Initialize Marketplace Action Request and Approve or Deny Marketplace Action Request
Initialize Marketplace Action Request is triggered when a user opens an issue requesting a specific marketplace action. The marketplace actions is "staged" as a private repo in your org where you intend to host the approved actions. Within this private repo, admins can review the marketplace action code and determine if it is appropriate for use within your enterprise. Actions are disabled on the newly created repo to prevent possible privilege escalation through self-hosted runners.
Approve or Deny Marketplace Action Request is triggered when a user comments on an issue. If the user commenting is a member of the approver's team, and the comment includes the word "approve", then the visibility of the repo created by the previous workflow is changed from "private" to "internal" (GHEC EMU and GHES >= 3.5, for GHES < 3.5 repos become "public" on approval) and the issue is closed. If the user commenting is a member of the approvers team, and the comment includes the word "deny", then the repo create by the previous workflow is put in "archive" mode and remains "private".
To request a marketplace action, open an issue in this repo. Include in your issue, the following markdown...
```json request
{
"owner": "hashicorp-contrib",
"repo": "setup-packer",
"version": "latest"
}
```
The example above refers to the repo https://github.com/hashicorp-contrib/setup-packer
. The value of the version
field needs to either match exactly a release in the repo, or be latest
. The value of latest
will cause the workflow to find the latest release available currently.
See examples.md for more examples.
actions-approved
for now.admin-ops
for now.admin-ops
org. Members of this team will be able to approve or deny requests for marketplace actions. Let's call it actions-approvers
for now.self-hosted
runners.TOKEN
with the value of a PAT that has admin:org
, repo
, and workflow
scope on your GHEC server.ADMIN_OPS_ORG
: admin-opsACTIONS_APPROVED_ORG
: actions-approvedACTIONS_APPROVERS_TEAM
: actions-approversYou may already have requests for marketplace actions occurring in another repo, and want to simply use these workflows in that repo.
When specifying the details of the actions repo you are requesting, if the release name and the tag name of the release in that repo do not match, you will need to use the tag name for the version. When specifying the version as latest
the assumption is that the release name and the tag name of the release match. If this is not the case, you will need to specify the tag name as the vesion rather than using latest
.