## Forking rules

This is a custom fork of [nektos/act](https://github.com/nektos/act/), for the purpose of serving [act_runner](https://gitea.com/gitea/act_runner).

It cannot be used as command line tool anymore, but only as a library.

It's a soft fork, which means that it will track the latest release of nektos/act.

Branches:

- `main`: default branch, contains custom changes, based on the latest release(not the latest of the master branch) of nektos/act.
- `nektos/master`: mirror for the master branch of nektos/act.

Tags:

- `nektos/vX.Y.Z`: mirror for `vX.Y.Z` of [nektos/act](https://github.com/nektos/act/).
- `vX.YZ.*`: based on `nektos/vX.Y.Z`, contains custom changes.
  - Examples:
    - `nektos/v0.2.23` -> `v0.223.*`
    - `nektos/v0.3.1` -> `v0.301.*`, not ~~`v0.31.*`~~
    - `nektos/v0.10.1` -> `v0.1001.*`, not ~~`v0.101.*`~~
    - `nektos/v0.3.100` -> not ~~`v0.3100.*`~~, I don't think it's really going to happen, if it does, we can find a way to handle it.

## Gitea-specific changes

### Matrix strategy: scalar values and template expressions

This fork extends the matrix strategy parser [workflow.go](pkg/model/workflow.go) to accept
bare scalar YAML values in addition to arrays, and to handle unevaluated template
expressions gracefully.

**Scalar wrapping**

A matrix key written without brackets is automatically promoted to a
single-element array:

```yaml
strategy:
  matrix:
    go-version: 1.21        # treated as [1.21]
    os: ubuntu-latest       # treated as ["ubuntu-latest"]
```

> [!NOTE]
> Previously such a value caused the matrix decoding to fail and the job ran *without*
> a matrix context (`matrix.*` variables were undefined). Now the job runs *one* matrix iteration with the scalar as the
> value. Existing workflows that used scalars by accident may see a difference in which matrix variables are populated.

**Template expression support (`${{ fromJSON(...) }}`)**

Template expressions in the matrix are resolved by `EvaluateYamlNode`
(`pkg/runner/runner.go`) *before* `Matrix()` is called.  When successful, the
expression is replaced by a proper YAML sequence and the matrix expands
normally.

If the expression cannot be resolved (e.g., the necessary context is not yet
available), the literal string is wrapped as a one-element array, and the job
runs once with the unexpanded string as the matrix value (graceful degradation).

---

![act-logo](https://raw.githubusercontent.com/wiki/nektos/act/img/logo-150.png)

# Overview [![push](https://github.com/nektos/act/workflows/push/badge.svg?branch=master&event=push)](https://github.com/nektos/act/actions) [![Join the chat at https://gitter.im/nektos/act](https://badges.gitter.im/nektos/act.svg)](https://gitter.im/nektos/act?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) [![Go Report Card](https://goreportcard.com/badge/github.com/nektos/act)](https://goreportcard.com/report/github.com/nektos/act) [![awesome-runners](https://img.shields.io/badge/listed%20on-awesome--runners-blue.svg)](https://github.com/jonico/awesome-runners)

> "Think globally, `act` locally"

Run your [GitHub Actions](https://developer.github.com/actions/) locally! Why would you want to do this? Two reasons:

- **Fast Feedback** - Rather than having to commit/push every time you want to test out the changes you are making to your `.github/workflows/` files (or for any changes to embedded GitHub actions), you can use `act` to run the actions locally. The [environment variables](https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables) and [filesystem](https://help.github.com/en/actions/reference/virtual-environments-for-github-hosted-runners#filesystems-on-github-hosted-runners) are all configured to match what GitHub provides.
- **Local Task Runner** - I love [make](<https://en.wikipedia.org/wiki/Make_(software)>). However, I also hate repeating myself. With `act`, you can use the GitHub Actions defined in your `.github/workflows/` to replace your `Makefile`!

# How Does It Work?

When you run `act` it reads in your GitHub Actions from `.github/workflows/` and determines the set of actions that need to be run. It uses the Docker API to either pull or build the necessary images, as defined in your workflow files and finally determines the execution path based on the dependencies that were defined. Once it has the execution path, it then uses the Docker API to run containers for each action based on the images prepared earlier. The [environment variables](https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables) and [filesystem](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#file-systems) are all configured to match what GitHub provides.

Let's see it in action with a [sample repo](https://github.com/cplee/github-actions-demo)!

![Demo](https://raw.githubusercontent.com/wiki/nektos/act/quickstart/act-quickstart-2.gif)

# Act User Guide

Please look at the [act user guide](https://nektosact.com) for more documentation.

# Support

Need help? Ask on [Gitter](https://gitter.im/nektos/act)!

# Contributing

Want to contribute to act? Awesome! Check out the [contributing guidelines](CONTRIBUTING.md) to get involved.

## Manually building from source

- Install Go tools 1.20+ - (<https://golang.org/doc/install>)
- Clone this repo `git clone git@github.com:nektos/act.git`
- Run unit tests with `make test`
- Build and install: `make install`