Fixes https://codeberg.org/forgejo/forgejo/issues/13503.
The existing implementation of `cancelled()` assumes that it is being invoked in a job execution context, not by the jobparser. Because Forgejo doesn't attempt to check the `if` conditions of jobs during a workflow cancel, I didn't implement this case -- but overlooked that including the function in an expression was still possible if meaningless, and therefore didn't test it.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1633): <!--number 1633 --><!--line 0 --><!--description Zml4OiBuaWwgZGVyZWZlcmVuY2Ugd2hlbiBFdmFsdWF0ZUlmIGlzIGNhbGxlZCB3LyBjYW5jZWxsZWQoKSBleHBy-->fix: nil dereference when EvaluateIf is called w/ cancelled() expr<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1633
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
https://code.forgejo.org/forgejo/runner/pulls/1585 introduced the environment variable `TEST_FEATURES` for switching tests related to particular feature on and off. For example, with `TEST_FEATURES=""`, tests that require Docker would be skipped. Unfortunately, that technique has multiple problems. Environment variables might not be passed on to child processes without it being clearly visible. Also, the usage differs by platform. On top of that, informational messages that are only related to testing were printed by the release binary.
Instead of the environment variable `TEST_FEATURES`, the command line flag `-features` is introduced:
```
$ go test ./... -args -features "docker,lxc"
```
That runs all tests that require the presence of Docker and LXC. It is also the default.
If tests that require Docker should be skipped, run:
```
$ go test ./... -args -features "lxc"
```
To exclude all tests that require the presence of a particular feature, run:
```
$ go test ./... -args -features "-"
```
At the moment, `-features` cannot be controlled when using make targets. That means that `make integration-test` runs all tests that require Docker or LXC.
Supersedes https://code.forgejo.org/forgejo/runner/pulls/1588.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- other
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1591): <!--number 1591 --><!--line 0 --><!--description dGVzdDogdXNlIGZsYWdzIGluc3RlYWQgb2YgZW52IHZhcmlhYmxlcyBmb3Igc2tpcHBpbmcgdGVzdHM=-->test: use flags instead of env variables for skipping tests<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1591
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
Tests involving Docker are skipped when `runtime.GOOS` is not `linux`. That is unnecessarily rigid and hinders development. There are other operating systems that can run Docker. It makes it impossible to run integration tests on Linux without Docker. Verifying that all tests that require Docker are skipped without Docker being present is impossible on Linux due to that, too.
Instead of relying on `runtime.GOOS`, developers can control whether tests involving Docker should be run with the help of the environment variable `TEST_FEATURES`.
If the variable is undefined, tests involving Docker will be run, because they are enabled by default:
```
$ make integration-test
```
That is the same as:
```
$ TEST_FEATURES="docker" make integration-test
```
If the variable does not contain the string `docker`, tests involving Docker will be **skipped**:
```
$ TEST_FEATURES="" make integration-test
```
If a test requires Docker, use `testutils.RequireTestFeatures(t, testutils.TestFeatureDocker)` to indicate that.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- other
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1585): <!--number 1585 --><!--line 0 --><!--description dGVzdDogdXNlIGVudmlyb25tZW50IHZhcmlhYmxlIGZvciBza2lwcGluZyBEb2NrZXIgdGVzdHM=-->test: use environment variable for skipping Docker tests<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1585
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
#1563 made changes to the `exprparser` library to allow detecting access to `env.*` and `secrets.*`. Two bugs were discovered during failed refactoring efforts (#1566):
- `env.*` and `secrets.*` weren't detected as access; in the event that these expressions were used in an `if` block they wouldn't have caused Forgejo to defer execution to the runner rather than doing server-side `if` evaluation
- `toJSON(matrix)` outputs a wrapping `"Matrix"` element, which was missed when dynamic `runs-on` capabilities were added, but missed until tests triggered similar problems in `env`
More comprehensive unit test cases around both are fixed here. Practically speaking neither bug is likely to occur in reality.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1572): <!--number 1572 --><!--line 0 --><!--description Zml4OiBleHByZXNzaW9uIGV2YWx1YXRpb24gZml4ZXMgZGlzY292ZXJlZCB3aGlsZSByZWZhY3RvcmluZyAnaWYnIGRldGVjdGlvbg==-->fix: expression evaluation fixes discovered while refactoring 'if' detection<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1572
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
The intent of this change is to allow Forgejo to evaluate `if` without having to send jobs to a runner. When you send a job to a runner just for it to return "skipped!", it takes up 1 runner capacity for a `fetch_interval` period, which can be avoided if Forgejo can evaluate the `if` condition itself.
Creates a new `EvaluateIf` function in the jobparser library's `Job` which evaluates the `if` clause, with these conditions:
- Requires that the `Job` is parsed by `jobparser.Parse` and has parsing context, such as job inputs, job results. If `Job` was serialized to yaml, then deserialized, this information would be missing and `EvaluateIf` would return an error.
- Accessing `env` and `secrets` is prohibited, and returns an error. Forgejo will react to this specific error by falling back to the current behaviour: send the task to the runner for `if` to be evaluated on the runner.
- `env` -- Currently Forgejo Runner can have configured [environment variables](22ebc7d1ab/internal/pkg/config/config.example.yaml (L26-L32)). As these values wouldn't be known to Forgejo, it doesn't make sense to access `env` in an `if` block from Forgejo.
- `secrets` -- Currently Forgejo doesn't provide secrets to the `jobparser`. I think it's risky to change this -- giving this information to the jobparser opens the door for it to end up in a marshalled `SingleWorkflow` through some error or future change, and be stored in the database insecurely and unencrypted.
Forgejo's implementation using these new APIs is https://codeberg.org/forgejo/forgejo/pulls/13030.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- features
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1563): <!--number 1563 --><!--line 0 --><!--description ZmVhdChqb2JwYXJzZXIpOiBpbXBsZW1lbnQgam9icGFyc2VyIGNhcGFiaWxpdHkgdG8gZXZhbHVhdGUgJ2lmJyBjbGF1c2Vz-->feat(jobparser): implement jobparser capability to evaluate 'if' clauses<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1563
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
When expanding the workflow below, the job parser fails to resolve `${{ matrix.BUILD_TARGET }}`. The reason is that properties in workflows are supposed to be case insensitive. To accomplish that, map keys are converted to lowercase before looking them up. But the lookup in that particular case didn't take that into account and expected the map keys' casing to match, which it no longer did.
```yaml
on:
push:
workflow_dispatch:
jobs:
one:
runs-on: debian
steps:
- run: echo OK
outer:
strategy:
matrix:
BUILD_TARGET: ['a', 'b', 'c']
uses: ./.forgejo/workflows/reusable.yaml
with:
build_param: ${{ matrix.BUILD_TARGET }}
```
Resolves https://codeberg.org/forgejo/forgejo/issues/12932.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- bug fixes
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1553): <!--number 1553 --><!--line 0 --><!--description Zml4OiBtYWtlIGxvb2stdXAgb2YgbWF0cml4IHZhbHVlcyBjYXNlLWluc2Vuc2l0aXZlIHdoZW4gZXhwYW5kaW5nIHdvcmtmbG93cw==-->fix: make look-up of matrix values case-insensitive when expanding workflows<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1553
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
Fixes#1501. As a jobparser upgrade, it requires Runner be released and Forgejo be upgraded to the new version.
When a reusable workflow caller has an `if:` condition on the job, it is placed on the expanded jobs that come from it. If an inner job of a reusable workflow also has an `if:` condition, the two conditions are `&&`'d together.
I originally planned to evaluate the `if` condition during job parsing, as described in [a comment on #1501](https://code.forgejo.org/forgejo/runner/issues/1501#issuecomment-85822). However, I realized that a common usage for `if` is job-status checks like `if: failed()`, and that cannot be evaluated at expansion time.
Manually tested with these workflows:
Caller:
```
on:
pull_request:
jobs:
top-true-inner-true:
if: true
uses: ./.forgejo/workflows/shared/child.yml
with:
value: first
top-true-inner-false:
if: true
uses: ./.forgejo/workflows/shared/child.yml
with:
value: not first
top-false:
if: false
uses: ./.forgejo/workflows/shared/child.yml
with:
value: would be second
```
Child:
```
name: Child workflow
on:
workflow_call:
inputs:
value:
type: string
required: true
jobs:
child-workflow:
runs-on: docker
if: ${{ inputs.value == 'first' }}
steps:
- name: Echo
run: echo ${{ inputs.value }}
```
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- features
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1509): <!--number 1509 --><!--line 0 --><!--description ZmVhdDogbWVyZ2UgcmV1c2FibGUgZXhwYW5zaW9uIGNhbGxlcidzICdpZicgaW50byBleHBhbmRlZCBqb2Jz-->feat: merge reusable expansion caller's 'if' into expanded jobs<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1509
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.code.forgejo.org>
Reduce Forgejo Runner's dependency on go-git further by incorporating its gitignore parsing and matching functionality into Forgejo Runner's source tree. Various alternative libraries were considered. However, those are either abandoned or have compatibility issues, or both.
Some unused functions in `dir.go` have been removed. go-git's internal abstractions were replaced with functionality provided by Go's standard library.
The original code can be found in 5b47ae8a22/plumbing/format/gitignore.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- other
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1497): <!--number 1497 --><!--line 0 --><!--description Y2hvcmU6IGluY29ycG9yYXRlIGdvLWdpdCdzIGdpdGlnbm9yZSBtYXRjaGluZw==-->chore: incorporate go-git's gitignore matching<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1497
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
Reusable workflow expansion is a capability that will allow Forgejo to schedule every job of a reusable workflow as a separate job, allowing the use of multiple runners and clear independent logging. This is a multi-PR implementation effort, project work tracking link: https://codeberg.org/forgejo/forgejo/issues/9768#issuecomment-8828016
This PR extends reusable workflow expansion such that if one job in a reusable workflow references another job via `${{ needs.some-job.outputs.some-output }}`, that expression is rewritten to reference the true ID of the job in the reusable workflow. The expression would be mutated to `${{ needs[format('{0}.{1}', 'reusable-1', 'some-job')].outputs.some-output }}`, where `'reusable-1'` is the job ID of the parent/caller job. With this change, jobs can reference each other, and are prevented from referencing other jobs in the workflow that aren't inside the scope of the reusable workflow.
In addition to test automation present here, this change has been manually tested on an [experimental Forgejo branch](https://codeberg.org/mfenniak/forgejo/pulls/3).
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- features
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1217): <!--number 1217 --><!--line 0 --><!--description ZmVhdChqb2JwYXJzZXIpOiByZXdyaXRlIHJldXNhYmxlIHdvcmtmbG93ICduZWVkcycgcmVmZXJlbmNlcyBiZXR3ZWVuIGpvYnM=-->feat(jobparser): rewrite reusable workflow 'needs' references between jobs<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1217
Reviewed-by: earl-warren <earl-warren@noreply.code.forgejo.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Reusable workflow expansion is a capability that will allow Forgejo to schedule every job of a reusable workflow as a separate job, allowing the use of multiple runners and clear independent logging. This is a multi-PR implementation effort, project work tracking link: https://codeberg.org/forgejo/forgejo/issues/9768#issuecomment-8828016
This PR extends reusable workflow expansion to support accessing the outputs of a reusable workflow. Four changes are involved:
- Centralizing a duplicated `rewriteSubExpression` function between the jobparser and the runner.
- Creating an expression mutator which allows for transformations of expressions by their abstract syntax tree.
- Transforming the outputs in `on.workflow_call.outputs`, which are in the form of `jobs.some-job.outputs`, into `needs[format("{0}.{1}", parent-job-id, job-id)].outputs....` on the parent job. This moves evaluation of the outputs into the placeholder job that was previously created in #1215 to support dependencies between jobs.
- Addition of a utility function `EvaluateWorkflowCallOutputs` which Forgejo can use to evaluate the outputs, as the placeholder job is never sent to a runner to be executed.
- Corrected an earlier persistent misuse of "callee" to refer to "caller".
In addition to test automation present here, this change has been manually tested on an [experimental Forgejo branch](https://codeberg.org/mfenniak/forgejo/pulls/3).
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- features
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1216): <!--number 1216 --><!--line 0 --><!--description ZmVhdChqb2JwYXJzZXIpOiBhbGxvdyBhY2Nlc3MgdG8gdGhlIG91dHB1dHMgb2YgYSByZXVzYWJsZSB3b3JrZmxvdw==-->feat(jobparser): allow access to the outputs of a reusable workflow<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1216
Reviewed-by: earl-warren <earl-warren@noreply.code.forgejo.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
**Note:** this PR is stacked on #1195.
Following the same pattern as #1190, this PR adds support for `${{ needs ... }}` within the `runs-on` field. It also extends the support of the `runs-on: ${{ matrix... }}` to include matrixes that are dynamically defined per #1190.
Minor additional changes are required in Forgejo to: use the new `SupportIncompleteRunsOn()` parse option, mark jobs as blocked when they come back as `IncompleteRunsOn`, and add related error handling and test automation cases.
Together these changes allow the accurate parsing of these jobs that aren't supported currently:
```yaml
on:
push:
jobs:
define-matrix:
runs-on: docker
outputs:
scalar-value: ${{ steps.define.outputs.scalar }}
array-value: ${{ steps.define.outputs.array }}
steps:
- id: define
run: |
echo 'scalar=debian-ci-latest' >> "$FORGEJO_OUTPUT"
echo 'array=["debian-latest", "debian-ci-latest"]' >> "$FORGEJO_OUTPUT"
runs-on-needs:
needs: define-matrix
runs-on: ${{ needs.define-matrix.outputs.scalar-value }}
steps:
- run: uname -a
runs-on-dynamic-matrix:
needs: define-matrix
strategy:
matrix:
runs-on:
- debian-latest
- "${{ needs.define-matrix.outputs.scalar-value }}"
runs-on: ${{ matrix.runs-on }}
steps:
- run: uname -a
```
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- features
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1194): <!--number 1194 --><!--line 0 --><!--description ZmVhdChqb2JwYXJzZXIpOiBzdXBwb3J0ICR7eyBuZWVkcy4uLiB9fSBpbiBydW5zLW9uIGFzIEluY29tcGxldGVSdW5zT24=-->feat(jobparser): support ${{ needs... }} in runs-on as IncompleteRunsOn<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1194
Reviewed-by: earl-warren <earl-warren@noreply.code.forgejo.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
It will be possible to report what `${{ needs... }}` value was referenced in a matrix that didn't exist, allowing better error messages in Forgejo.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- features
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1193): <!--number 1193 --><!--line 0 --><!--description ZmVhdChqb2JwYXJzZXIpOiBlbmhhbmNlIGluY29tcGxldGVfbWF0cml4IHdpdGggaW5mb3JtYXRpb24gYWJvdXQgd2hhdCBqb2IgJiBvdXRwdXQgd2FzIGFjY2Vzc2Vk-->feat(jobparser): enhance incomplete_matrix with information about what job & output was accessed<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1193
Reviewed-by: earl-warren <earl-warren@noreply.code.forgejo.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/71 requires partial implementation in runner, and partial in Forgejo; this is the runner implementation.
Extends the jobparser module to support matrix jobs that reference the outputs of other needed jobs, for example:
```yaml
jobs:
define-matrix:
outputs:
colors: ${{ steps.colors.outputs.colors }}
steps:
- name: Define Colors
id: colors
run: |
echo 'colors=["red", "green", "blue"]' >> "$GITHUB_OUTPUT"
produce-artifacts:
needs: define-matrix
strategy:
matrix:
color: ${{ fromJSON(needs.define-matrix.outputs.colors) }}
```
The intended workflow for `jobparser` to support this is:
- The workflow is passed to jobparser as usual, but the new `ParseOption` `WithJobOutputs()` is provided. It can be an empty set of outputs at the beginning of a workflow.
- The `SingleWorkflow` that is returned may be tagged with `IncompleteMatrix: true`. If so, this is a job that has `needs` that must be completed before its matrix can be evaluated.
- Later when the jobs listed in `needs` are complete, the `SingleWorkflow`'s content can be passed back to the jobparser with `WithJobOutputs()` that includes all of the needed jobs' outputs. At this point the single job will be reevaluated and multiple jobs may be returned.
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- features
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1190): <!--number 1190 --><!--line 0 --><!--description ZmVhdChqb2JwYXJzZXIpOiBzdXBwb3J0IHJlZmVyZW5jaW5nICR7eyBuZWVkcy4uLiB9fSB2YXJpYWJsZXMgaW4gYHN0cmF0ZWd5Lm1hdHJpeGA=-->feat(jobparser): support referencing ${{ needs... }} variables in `strategy.matrix`<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1190
Reviewed-by: earl-warren <earl-warren@noreply.code.forgejo.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
This PR contains two fixes to the production code:
- 20d56ace53adf26f66e7eb14f3f899087aec70eb fixes the `hashFile` function in an action misinterpreting paths on Windows
- 4e2609329dc2e3e630a67c3237e38a92dd7dc784 fixes the `validate` command outputting full paths due to OS-unspecific path trimming logic
The remaining changes adopt tests to properly deal with
- Docker with Linux containers not being available on standard Windows runners c492fe121e2f2d2eb6dbc8fd5b1cef543437fa99
- Windows paths (6781d823683428d5cf8b9bac4753a458882b5994), (8ca14d0f4d4274e808fb027e021bac701279381e), (eb70aca72c89c08cdc03c35dd26f3e57bdeaacac), (4e2609329dc2e3e630a67c3237e38a92dd7dc784), (c00d4e0a81634c098086b822884eb6b525ebe933)
- Revert a change causing a test-runner panic on Windows (6608fec705f7e7ed48c7ffed3839f2b4c4c1defb)
- Exclude the daemon suicide test because it cannot be properly observed on Windows (3ef33b93b6c3422ce47325bc5330d2d954998cf4)
or in one case separate dedicated Windows and Linux test setups (709a1d3fdbfc8a6149a57fcf00570e842ef4d040)
I tried to keep the changes as minimal as possible and focussed on getting the tests to run again.
I only added skips for tests that I could not get to run due to the Docker requirements, or the different shutdown behaviors on Linux and Windows.
In the future, I will investigate why the defensive `chdir` in `linux_container_environment_extensions_test.go` (6608fec705f7e7ed48c7ffed3839f2b4c4c1defb) is necessary and whether I can get all of the docker tests (c492fe121e2f2d2eb6dbc8fd5b1cef543437fa99) to run on GitHub Actions
The passing of all tests on windows has been confirmed [here](https://github.com/Crown0815/Forgejo-runner-windows-builder/actions/runs/19344650459).
<!--start release-notes-assistant-->
<!--URL:https://code.forgejo.org/forgejo/runner-->
- other
- [PR](https://code.forgejo.org/forgejo/runner/pulls/1152): <!--number 1152 --><!--line 0 --><!--description V2luZG93cy1zcGVjaWZpYy1maXhlcw==-->Windows-specific-fixes<!--description-->
<!--end release-notes-assistant-->
Co-authored-by: Felix Krรถner <felix.kroener@bruker.com>
Reviewed-on: https://code.forgejo.org/forgejo/runner/pulls/1152
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.code.forgejo.org>
Co-authored-by: Crown0815 <crown0815@noreply.code.forgejo.org>
Co-committed-by: Crown0815 <crown0815@noreply.code.forgejo.org>
To prepare for a smooth merge in the runner codebase.
- run with --fix for gofumpt and golangci
- manual edits for
- disabling useless package naming warning
- rename variables that had underscore in their name
- remove trailing else at the end of a few functions
Reviewed-on: https://code.forgejo.org/forgejo/act/pulls/206
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
- upgrade to golangci-lint@v1.62.2
- make it renovate friendly
- remove most frequent lint check that are not of consequence (unused
args, etc.)
- fix remaining lint errors
- add renovate custom manager to update the Makefile variable
* fix: use actions/runner hashfiles in container
Previously hashfiles ran on the host,
this don't work for container generated content
* fix: lint
* fix: lint
* fix assign follow symlink flag
Co-authored-by: Jason Song <i@wolfogre.com>
---------
Co-authored-by: Jason Song <i@wolfogre.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* feature: Add support for github action variables
* add --var flag for github variables
* unitests: Updated unittests to cover vars context.
* Remove syntax extension for vars and correct unit tests
* Update pkg/runner/expression.go
Co-authored-by: ChristopherHX <christopher.homberger@web.de>
---------
Co-authored-by: kuanyong-wong-partior <kuanyong.wong@partior.com>
Co-authored-by: ChristopherHX <christopher.homberger@web.de>
* fix: map job output for reusable workflows
This fixes the job outputs for reusable workflows. There is
a required indirection. Before this we took the outputs from
all jobs which is not what users express with the workflow
outputs.
* fix: remove double evaluation
---------
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* Support "result" on "needs" context.
This change adds "result" to a job's "needs" context, as documented [here](https://docs.github.com/en/actions/learn-github-actions/contexts#needs-context). `act` currently tracks the success/failure/cancelled status of a job, but does not include this value the `needs` context.
Fixes#1367
* Change `Needs` to use a new struct rather than the open type `interface{}`.
Related #1497Fixes#1367
* Add integration test to "needs" context change.
Relates: #1497
* feat: allow to spawn and run a local reusable workflow (#1423)
* feat: allow to spawn and run a local reusable workflow
This change contains the ability to parse/plan/run a local
reusable workflow.
There are still numerous things missing:
- inputs
- secrets
- outputs
* feat: add workflow_call inputs
* test: improve inputs test
* feat: add input defaults
* feat: allow expressions in inputs
* feat: use context specific expression evaluator
* refactor: prepare for better re-usability
* feat: add secrets for reusable workflows
* test: use secrets during test run
* feat: handle reusable workflow outputs
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* refactor: fix savestate in pre steps (#1466)
* refactor: fix savestate in pre steps
* fix pre steps collision
* fix tests
* remove
* enable tests
* Update pkg/runner/action.go
* Rename InterActionState to IntraActionState
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* fix: tail (not absolute) as entrypoint of job container (#1506)
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* Fix conflict in merge.
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* fix: support docker create arguments from container.options (#1022)
* fix processing of errors, add verbose logging, fix test
* disable linter for code copied from docker/cli
* fix all linter issues
* Add license info
* Add opts_test.go from docker/cli and required testdata
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* feat: add post step to actions and add state command
This commit includes requried changes for running post steps
for local and remote actions.
This allows general cleanup work to be done after executing
an action.
Communication is allowed between this steps, by using the
action state.
* feat: collect pre and post steps for composite actions
* refactor: move composite action logic into own file
* refactor: restructure composite handling
* feat: run composite post steps during post step lifecycle
* refactor: remove duplicate log output
* feat: run all composite post actions in a step
Since composite actions could have multiple pre/post steps inside,
we need to run all of them in a single top-level pre/post step.
This PR includes a test case for this and the correct order of steps
to be executed.
* refactor: remove unused lines of code
* refactor: simplify test expression
* fix: use composite job logger
* fix: make step output more readable
* fix: enforce running all post executor
To make sure every post executor/step is executed, it is chained
with it's own Finally executor.
* fix: do not run post step if no step result is available
Having no step result means we do not run any step (neither pre
nor main) and we do not need to run post.
* fix: setup defaults
If no pre-if or post-if is given, it should default to 'always()'.
This could be set even if there is no pre or post step.
In fact this is required for composite actions and included post
steps to run.
* fix: output step related if expression
* test: update expectation
* feat: run pre step from actions (#1110)
This PR implements running pre steps for remote actions.
This includes remote actions using inside local composite actions.
* fix: set correct expr default status checks
For post-if conditions the default status check should be
always(), while for all other if expression the default status
check is success()
References:
https://docs.github.com/en/actions/learn-github-actions/expressions#status-check-functionshttps://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runspost-if
* fix: remove code added during rebase
