starred/act

Fork 0

mirror of https://github.com/nektos/act.git synced 2026-04-26 09:25:54 +03:00

[PR #1709] [CLOSED] feature: reference workflowpattern package to add workflow filtering #2085

New issue

Closed

opened 2026-03-01 21:53:56 +03:00 by kerem · 0 comments

kerem commented

2026-03-01 21:53:56 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/nektos/act/pull/1709
Author: @ae-ou
Created: 4/2/2023
Status: ❌ Closed

Base: master ← Head: feature-reference-workflow-pattern-package

📝 Commits (7)

9d94a76 Get filter patterns nested within the the On attribute of the workflow.
2a582fd Add a ShouldFilterWorkflow() function. Testing is still needed for this function, and we need to determine a way to pass the payload down to the function in order to check it using filters.@
5f88d0a Switch to FilterStruct
e7702b9 Handle the '*-ignore' filter paths, and return a log.Fatal() if a filter and the *ignore variant (e.g. 'paths' and 'paths-ignore') are both set. Define the function signature in workflow_pattern so that I can easily reference the signature for Skip()/Filter(). Add TODOs.
9d7a369 Merge branch 'master' into feature-reference-workflow-pattern-package
772062e Merge branch 'nektos:master' into feature-reference-workflow-pattern-package
64bef7a Merge branch 'nektos:master' into feature-reference-workflow-pattern-package

📊 Changes

4 files changed (+546 additions, -0 deletions)

View changed files

📝 pkg/model/planner.go (+7 -0)
📝 pkg/model/workflow.go (+139 -0)
📝 pkg/model/workflow_test.go (+397 -0)
📝 pkg/workflowpattern/workflow_pattern.go (+3 -0)

📄 Description

Description

This is a followup to https://github.com/nektos/act/pull/1618 by @ChristopherHX - which added in a package to accommodate filtering. This PR works to invoke the filtering when the act command is executed.

This PR is in a draft state - there are a number of questions that I'm not in a position to answer (which are outlined in the "Questions" section below), and I can't complete this PR without these questions being answered. Feedback/answers to my questions are much appreciated.

Changes Thusfar

Add a FindFilterPatterns() function to the Workflow struct.
- This function checks to see if the specified event supports filtering (i.e. pull_request or push), it then traverses the nodes in WorkFlow.RawOn and builds up a struct (FilterPatterns) containing slices of filters.
Add a ShouldFilterWorkflow() function to the Workflow struct.
- This function calls FindFilterPatterns() to get the filters patterns (relating to the specified event) on the workflow, it then compiles these patterns into Regex, and compares the provided event against the patterns (to determine whether the workflow should be added to the plan).
Define a function signature (workflowpattern.FilterInputsFunc)
- this is the signature that both workflowpattern.Skip() and workflowpattern.Filter() implement.

Notes

I had initially looked at changing RawOn to a struct, so that we could directly unmarshal any filters found in the workflow into this struct.
- I decided against this as it would require refactoring/regression testing anything that already makes use of RawOn.
There are a number of TODO comments in my code - some of these are the basis for questions below.

Questions

How should I provide the Github event to the ShouldFilterWorkflow() function? Since I will probably call ShouldFilterWorkflow() within the functions on model.workflowPlanner struct, should I store a copy of the event on this struct?
1. The runner.runnerImpl.configure() function builds up an eventJson attribute, but none of these functions/structs are exported.
  1. At the time that we plan events/jobs (in cmd.newRunCommand()), we haven't called r, err := runner.New(config), so this structure wouldn't be available to the planner - even if the attribute was exported.
2. The model.GithubContext struct appears to relate to the Github event, but there's no function to unmarshal a JSON file into the struct.
Do we need to check the workflow filters when calling workflowPlanner.PlanJob()? Filters are a workflow-level attribute (and a Job exists as a component of a workflow file) but some users may wish to invoke a job without the context of its wider workflow.
Should I alter my existing functions (FindFilterPatterns() and ShouldFilterWorkflow()) to return errors instead of calling log.Fatal()?
1. I used log.Fatal() in line with the other functions in the model package, as I saw very few error return values on function signatures.
2. Personally, I prefer returning errors from packages as they're easier to test. I also saw a PR (https://github.com/nektos/act/pull/1705) which is working on replacing log.Fatal()
If users provide events (using the -e flag) that don't satisfy the conditions on their workflow file, the addition of filtering may break the workflows for those users. Is there a preferred way to communicate this change to those users?

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/nektos/act/pull/1709 **Author:** [@ae-ou](https://github.com/ae-ou) **Created:** 4/2/2023 **Status:** ❌ Closed **Base:** `master` ← **Head:** `feature-reference-workflow-pattern-package` --- ### 📝 Commits (7) - [`9d94a76`](https://github.com/nektos/act/commit/9d94a76fee788918cd4967308449bc3cbb88d80e) Get filter patterns nested within the the On attribute of the workflow. - [`2a582fd`](https://github.com/nektos/act/commit/2a582fde0aed06ad5116ce71938427069f52150a) Add a ShouldFilterWorkflow() function. Testing is still needed for this function, and we need to determine a way to pass the payload down to the function in order to check it using filters.@ - [`5f88d0a`](https://github.com/nektos/act/commit/5f88d0a801900350ccc50a2c7cbdf653bdefcb92) Switch to FilterStruct - [`e7702b9`](https://github.com/nektos/act/commit/e7702b9fc1a624666cc70e944a67c62e4e9ed8cc) Handle the '*-ignore' filter paths, and return a log.Fatal() if a filter and the *ignore variant (e.g. 'paths' and 'paths-ignore') are both set. Define the function signature in workflow_pattern so that I can easily reference the signature for Skip()/Filter(). Add TODOs. - [`9d7a369`](https://github.com/nektos/act/commit/9d7a369858d1142ed908bb7be86f8840ed9eb8c3) Merge branch 'master' into feature-reference-workflow-pattern-package - [`772062e`](https://github.com/nektos/act/commit/772062e805ed3e953917c4f78165456754cb592a) Merge branch 'nektos:master' into feature-reference-workflow-pattern-package - [`64bef7a`](https://github.com/nektos/act/commit/64bef7ab4ae82784ec51ce4cf7666fea19b2f75d) Merge branch 'nektos:master' into feature-reference-workflow-pattern-package ### 📊 Changes **4 files changed** (+546 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `pkg/model/planner.go` (+7 -0) 📝 `pkg/model/workflow.go` (+139 -0) 📝 `pkg/model/workflow_test.go` (+397 -0) 📝 `pkg/workflowpattern/workflow_pattern.go` (+3 -0) </details> ### 📄 Description ## Description This is a followup to https://github.com/nektos/act/pull/1618 by @ChristopherHX - which added in a package to accommodate filtering. This PR works to invoke the filtering when the `act` command is executed. **This PR is in a draft state** - there are a number of questions that I'm not in a position to answer (which are outlined in the "Questions" section below), and I can't complete this PR without these questions being answered. Feedback/answers to my questions are much appreciated. ## Changes Thusfar * Add a `FindFilterPatterns()` function to the `Workflow` struct. * This function checks to see if the specified event supports filtering (i.e. `pull_request` or `push`), it then traverses the nodes in `WorkFlow.RawOn` and builds up a struct (`FilterPatterns`) containing slices of filters. * Add a `ShouldFilterWorkflow()` function to the `Workflow` struct. * This function calls `FindFilterPatterns()` to get the filters patterns (relating to the specified event) on the workflow, it then compiles these patterns into Regex, and compares the provided event against the patterns (to determine whether the workflow should be added to the plan). * Define a function signature (`workflowpattern.FilterInputsFunc`) * this is the signature that both `workflowpattern.Skip()` and `workflowpattern.Filter()` implement. ## Notes * I had initially looked at changing `RawOn` to a struct, so that we could directly unmarshal any filters found in the workflow into this struct. * I decided against this as it would require refactoring/regression testing anything that already makes use of `RawOn`. * There are a number of `TODO` comments in my code - some of these are the basis for questions below. ## Questions 1. How should I provide the Github `event` to the `ShouldFilterWorkflow()` function? Since I will probably call `ShouldFilterWorkflow()` within the functions on `model.workflowPlanner` struct, should I store a copy of the `event` on this struct? 1. The `runner.runnerImpl.configure()` function builds up an `eventJson` attribute, but none of these functions/structs are exported. 1. At the time that we plan events/jobs (in `cmd.newRunCommand()`), we haven't called `r, err := runner.New(config)`, so this structure wouldn't be available to the `planner` - even if the attribute was exported. 3. The `model.GithubContext` struct appears to relate to the Github event, but there's no function to unmarshal a JSON file into the struct. 2. Do we need to check the workflow filters when calling `workflowPlanner.PlanJob()`? Filters are a workflow-level attribute (and a Job exists as a component of a workflow file) but some users may wish to invoke a job without the context of its wider workflow. 3. Should I alter my existing functions (`FindFilterPatterns()` and `ShouldFilterWorkflow()`) to return errors instead of calling `log.Fatal()`? 1. I used `log.Fatal()` in line with the other functions in the `model` package, as I saw very few `error` return values on function signatures. 2. Personally, I prefer returning errors from packages as they're easier to test. I also saw a PR (https://github.com/nektos/act/pull/1705) which is working on replacing `log.Fatal()` 4. If users provide events (using the `-e` flag) that don't satisfy the conditions on their workflow file, the addition of filtering may break the workflows for those users. Is there a preferred way to communicate this change to those users? --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

kerem

2026-03-01 21:53:56 +03:00

closed this issue
added the
pull-request
label

kerem referenced this issue

2026-03-01 21:54:41 +03:00

[PR #2087] [MERGED] Evaluate if condition when calling a reusable workflow #2261

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/act#2085

No description provided.

Rows
Columns