redhat-actions / common

Repository for shared config files, actions and planning.

Red Hat Actions Common

This repository contains the common Actions and config files for developing the Red Hat GitHub Actions.

• action-io-generator is an NPM package and (soon to be) Docker Action that makes sure your JavaScript action uses the same Inputs and Outputs defined in your action.yml.
• bundle-verifier is a JavaScript Action that makes sure your JavaScript action's committed distribution bundle is up-to-date.
• commit-data is a Docker Action that outputs some commonly needed data about the current workflow's HEAD commit.
• config-files contains our shared TypeScript, ESLint, and Webpack configs.

It is also used for tracking issues that don't fit into another, more specific repository.

common's Issues

As a user I want to build an image of the application using source to image

Outcome:

• Action to build an image using s2i
• Provide support to Linux, Windows, MacOSX
• Output Image digest so that can be used in other actions.

From redhat-developer/openshift-actions#57

TODOs post CRDA action release

• Add a deprecated notice in the previous CRDA action
• Update CRDA action in CRDA cli docs
• redhat-actions/starter-workflows#4 #53

Propose a naming scheme for actions

From redhat-developer/openshift-actions#55

Explore the creation of a Login action

From: redhat-developer/openshift-actions#54

[FEATURE] GitHub Action to Check CVE-2021-42574 and CVE-2021-42694

Is your feature request related to a problem? Please describe.

Recently, Red Hat published RHSB-2021-007 Trojan source attacks
(CVE-2021-42574,CVE-2021-42694) and attached a script that detects
unicode control characters.

In our team, we would like to use the published script in our GH
actions CI workflows so that we can trust more external
contributions.

Describe the solution you'd like

A new GH action that uses the published diagnostic tool:
https://access.redhat.com/security/vulnerabilities/RHSB-2021-007#diagnostic-tools
to detect Unicode control characters.

Describe alternatives you've considered

None, other than hosting this action in a personal account or in a different
organization.

Additional context

Tool output:

$ ./find_unicode_control2.py -d .
<filename>:11097 unicode control characters: ['\u200d']
<filename>:12987 unicode control characters: ['\u200d']

---

Please, let me know if this is the best place to ask this!

Org runner/auth integrations

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

As a developer I would like to have an action to set up CEKit

I have already created a draft: https://github.com/dev-actions/setup-cekit

RedHat github actions site should be verified.

Github supports verified URLs on the site main page.
Similar to this verified site.
https://github.com/openshift

The process is described here, we need to

1. decide which urls we want to verify. Currently we direct people to redhat.com
2. work with the redhat.com IT people to get the DNS records modified to allow verification

Explore build container alternatives

redhat-developer/openshift-actions#53

Add changelog when we create new release of the actions

It will be nice if we can provide a changelog when we have new release of the actions, that will help users to track what's new in the current version.

Single User Bot to Manage Secrets, tokens

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Operator for Runner: Evaluate Runner Controllers

Is your feature request related to a problem? Please describe.

The current solution for adding an OpenShift runner is via a user installed Helm Chart - which enables individuals and teams to configure a cluster manually for self hosted runners on openshift.

Describe the solution you'd like

A Github Actions runner operator supporting a set of CRs for simplified configuration and management of manage runner instances for clusters.
This runner needs to be configured to be compatible with all RH actions. A runner could be configured to org level use so that end users could make runners available across multiple repos easily with no additional configuration.

An example of a runner controller is here https://github.com/actions-runner-controller/actions-runner-controller
Note this controller uses DIND for Docker builds but we would prefer Buildah

Describe alternatives you've considered

Individual teams can continue to use a manually installed helm chart as described here for each repo.
https://github.com/redhat-actions/openshift-actions-runner-installer

Additional context

Create blog usage for new action workflow

Create a blog to document github actions

• sample wokflows
• actions from redhat
• request for feedback/ community

From redhat-developer/openshift-actions#62

Quay.io Registry Actions (clair scans)

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Add a workflow to help users without Dockerfile

Burr Sutter has a use case where he wants to have a copy and paste workflow at someplace so that users (students) who don't have a handy Dockerfile can use this workflow to deploy on OpenShift.
His idea is to have a workflow with actions s2i-build, push-to-registry(push to ghcr.io), oc-login, oc-new-app.

GitHub App PoC

A base GitHub App for the redhat-actions must:

• Run containerized in OpenShift
• Not require administrator permissions or a non-restricted SCC

The app will:

• Provide a frontend accessible in-cluster which the user can launch to authenticate with GitHub (#36)
• Allow the user to select repositories they wish the app to have access to (through github oauth flow)

For authorized repositories, the app:

Must:

• Create secrets into the repository which contain the OpenShift server URL and credentials (#30)
  • While a temporary token could be used at first, we will create a serviceaccount and use its token as documented in the wiki
• Create a workflow with oc-login step with the secrets matching those created by the app

Should:

• Create workflow from starter workflow
  • Prewritten workflows to build different project types
• Inject oc-login step into an existing workflow job
• Set up OpenShift integrated image registry
  • Push (using push-to-registry)
  • Pull (requires podman login)

Stretch:

• Install self-hosted runners (could be a separate app entirely) (#29)

operator-sdk installer

There is interest in creating an action to install and cache the operator-sdk executable

The upstream releases are here: https://github.com/operator-framework/operator-sdk/releases

The downstream releases are here: https://mirror.openshift.com/pub/openshift-v4/clients/operator-sdk/latest/

Most users seem to be using upstream but we may get downstream for very little effort through the openshift-tools-installer

There is also this example from the sandbox team of installing an upstream build (no caching)

Document criteria to publish action

Release process, housekeeping (icons, categorization)

From redhat-developer/openshift-actions#61

As a developer, I want to deploy an Application as a Knative Service on OpenShift so that my application can automatically scale based on the number of requests

Assumptions:

• The cluster has internet access

• Namespace already available

Outcomes:

• Find missing parts or potential improvements (for next sprint)

From redhat-developer/openshift-actions#47

Install/Manage runners for namespace

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Integration to Sandbox, login/auth

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Update buildah, PTR and oc-new-app readmes to point to podman-login action

As a developer I would like to be able to test my Openshift specific yaml inside GitHub actions using crc

Today there are github actions to start a kind cluster https://github.com/marketplace/actions/kind-kubernetes-in-docker-action as a github action.

Instead of starting a kind environment I would like to have openshift crc or something similar running inside a github action so I can test my open-source OCP specific yaml without having to have a OCP cluster running somewhere else.

As a user I want to build an image of my application using buildah

From redhat-developer/openshift-actions#56

As a user I want to reuse a Kubernetes action from GitHub Marketplace with OpenShift so that I can deploy my app reusing an existing Kubernetes workflows

Assumptions:

• Cluster is accessible through the Internet
• Namespace already available

Potential outcomes/questions:

• Login action
• Login kube context needs to persist to subsequent jobs
• How does Azure/GKE handle this?

From redhat-developer/openshift-actions#48

[FEATURE] podman service as an action

Is your feature request related to a problem? Please describe.

I would like to have a Github Action that will start podman service for both rootless and rootfull modes.
Podman service can be enabled using systemd:

# rootful mode
sudo systemctl -enable --now podman.socket
# rootless mode
systemctl --user enable --now podman.socket

There are some rough edges in rootless mode. Github instances don't have /lib/systemd/systemd --user process running. You have to enable lingering:

loginctl enable-linger $(whoami)

Besides XDG_RUNTIME_DIR is not defined therefore there should another command:

export XDG_RUNTIME_DIR=/run/user/$UID

Describe the solution you'd like

It would be nice to hide these preparations behind a Github Action:

name: Enable podman service
uses: redhat-actions/[email protected]
with:
   rootful: false

Describe alternatives you've considered

As an alternative, I could do these steps manually as I described in my blog post

Map GitHub actions to Tekton tasks inventory on OpenShift

OpenShift pipelines has a built in set of tasks.
For consistency, we need to evaluate the tekton tasks inventory and determine if any of those tasks can be mapped to actions.

Secondary - implementation details - can we used tekton as implementation (on cluster) or create a tekton as launcher for tekton as code.

From redhat-developer/openshift-actions#63

Update helm install with oc-new-app action

Fork of Spring petclinic workflow is using helm install, once we release oc-new-app action then it worth replacing helm install with oc-new-app action.

CRDA Scanner PoC

Create a github action to run a CRDA scan on the repository.
If SARIF output is available upload to github as a security scan

Update openshift starter workflow

Once we release oc-new-app action then we should update the starter workflows for the openshift.
As it is using scripts to deploy application on openshift, but after the release of oc-new-app action we can change that with this action as it satisfies our requirements.

Also, since we have released v2 version of push-to-registry action and buildah-build action, so it's worth updating these actions in the starter workflows.

Test automation for starter workflow

We need nightly testing for the starter workflow. This repo could be a good place. https://github.com/redhat-actions/starter-workflows

Podman login action

There is need to create an action to login to against a container registry, as few of our actions has features that expects login to be done before running that action, at present we recommend users to do something like:

- name: Log in to Red Hat Registry
  run: echo "${{ secrets.REGISTRY_REDHAT_IO_PASSWORD }}" | docker login registry.redhat.io -u "${{ secrets.REGISTRY_REDHAT_IO_USER }}" --password-stdin

and also few users use scripts to login to the container registry. So, by adding this action it will be bit easy for users to login to container registry.

There is already docker login action, but this way you have to have docker installed.

Explore about source to image for building an image.

To explore about source to image tool and understand what it takes to build an action for the s2i.

From redhat-developer/openshift-actions#59

Github App features

As a user, I should be able to install a github app for my personal use to manage my secrets and other github issues

Create a blog post for CRDA action

After the release of this action, a blog post should be created on RedHat Developer

oc-new-app Action

User should be able to create deployment of the application using already built image.
oc new-app command can be used to solve this.

As a user I want to push an image to a image registry of my choice.

Outcome:

• Push action to push an image to registry

From redhat-developer/openshift-actions#58

Single User/Repo Runner on OpenShift

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Ensure team has access to clusters for the development

From: redhat-developer/openshift-actions#52

Add new Starter workflows

Github has added the ability to create multiple starters. Previously they had restricted the starters to a single per partner. The now allow multiple in the following categories

CD - this is where the current openshift starter lives
CI - Language specific CI workflows (options for Java or Quarkus here)
Automation - Github specific integrations for workflows
Security - CRDA and Clair/Stackrox action as examples

Add cron jobs to actions

Few of our action has external dependency like installing binary from any other source. At some point of time download path may change and that may be a breaking change (although this would be in a very rare case) so adding a cron in workflow might be a good thing to keep a check of any breaking change.

Actions that we should consider for this as of now:

• oc-installer
• s2i-build
• kn-service-manager
• buildah-build
• push-to-registry
• oc-login
• oc-new-app

Note: openshift-tools-installer already has cron job setup.

Actions for writing and maintaining other actions

There are a number of "meta-actions" which may be useful in maintaining our existing actions, to enforce consistency between the actions. As with any automation, the cost of writing and maintaining the action must be worth the time savings it will provide in the long run.

All our action already use the bundle-verifier which I think has been really useful. But, I wanted to document the other ideas I have here, whether or not we actually go through with writing them and adding them to all our actions.

1. Input and output enum generator https://github.com/redhat-actions/oc-login/blob/main/scripts/generate-ins-outs.ts

• This script reads in the action.yml and outputs a pair of enums with the action's Inputs and Outputs complete with their descriptions.
• oc-login already uses this in this workflow
• I find this really nice because it ensures the names of the inputs and outputs in the TS match the action.yml, so you won't ever look for an input/output that has the wrong name (eg, due to a typo).
• Ideally the input-output generator script would run automatically on change to action.yml rather than having to invoke it manually.
• However, the inputs and outputs still have to be copied by hand into the README. I thought about generating a markdown table based on the action.yml but it was hard to figure out how to insert it into the readme.

2. Input and output naming

• Tying into above, our inputs and outputs should all use the same convention. Actions does not provide any explicit recommendation for naming, and the ecosystem has a mix of kebab-case and snake_case.
• We should pick one and stick to it. Most are currently snake_case but unfortunately we were not careful enough and have a few that are currently kebab-case which we should fix.
• This could be enforced with an action similar to above.

3. Secret and env naming

• In all our workflows, we should enforce CONSTANT_CASE for naming secrets and environment variables. We have stuck to this so far, so I am not too worried about automating this one.
• We should use consistent secret naming between our actions. For example, if one workflow uses secrets.OPENSHIFT_URL, that name should always be used - rather than eg. OPENSHIFT_SERVER_URL.

4. TS Linting

• Currently, oc-installer, s2i-build and oc-login use eslint. The former two have a overly complex config file which is not actually used in CI. I've just added a simple one for the third and added it to a workflow.
• All our TS actions should share a config file and run it in CI. Ideally, it would be stored in one place only rather than being duplicated across repositories.

5. Caching npm dependencies

• All our TS/JS workflows have to npm ci before they can run any of their own CI checks, since they need access to the devDependencies to run eg. tsc or eslint.
• We should find a reusable way to fetch the npm dependencies from the cache, rather than performing the full download every single job.
• https://github.com/bahmutov/npm-install looks like a good, existing solution to this problem.

Figure out a way to cache docker image layers

There has to be a way to cache docker image layers so the whole image doesn't have to be rebuilt every job.

Self-hosted runners would be a good solution. Maybe we can find a way for GitHub runners too.

Test cluster provisioning from Actions

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Tekton Task Runner Action (shift left)

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Add CRDA action in code scanning starter workflow

If GitHub allows multiple starter workflows per organization in the future, then we can add CRDA action to the code scanning section in the starter workflows.
Ref: #51

Single User/Repo Runner on OpenShift

Configuration of RH Entitlements

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

As a developer I want to deploy an application to my openshift cluster behind a VPN

Many customers have clusters behind VPN or without direct internet access (proxy, etc) but still would like to use Github Actions to deploy applications.

From: redhat-developer/openshift-actions#51

Document setting up CRC in Actions

Resource requirements prevent CRC from working in GitHub hosted runners.

But we can write and document steps to get CRC working in a self-hosted environment, and detail the requirements we'd need for GitHub hosting.