I can't get if: ${{ always() }} / if: always() working (with master) #442
Labels
Milestone
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
From what I can tell, Lines 60 to 66 in e6fcfed I'm not exactly sure how to go about resolving this, but any pointers would be appreciated - I'd be happy to help PR a solution. I did notice that there was a update: It looks like |
|
So when I understand it right, the feature actually does not exists or is not fully implemented. Sadly I am currently not able to invest time to help with a PR. I think the feature itself is needed to replicate the behavior on Github and hope that it can be added without too much of an investment. |
|
Yes, my understanding is that the feature is not implemented in |
This comment has been minimized.
This comment has been minimized.
|
I'm experiencing the same scenario. It would be great to have this functionality as part of act. |
catthehacker
added
area/workflow
|
Same here. This feature would be an excellent addition. |
KnisterPeter
added a commit
to xing/act
that referenced
this issue
Oct 14, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
ZauberNerd
added a commit
to xing/act
that referenced
this issue
Oct 28, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
KnisterPeter
added a commit
to xing/act
that referenced
this issue
Nov 4, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
ZauberNerd
added a commit
to xing/act
that referenced
this issue
Nov 17, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
ZauberNerd
added a commit
to xing/act
that referenced
this issue
Nov 22, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
ZauberNerd
added a commit
to xing/act
that referenced
this issue
Nov 23, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
ZauberNerd
added a commit
to xing/act
that referenced
this issue
Nov 23, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Nov 23, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Nov 23, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Nov 23, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Nov 23, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Nov 23, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Nov 23, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Nov 23, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Nov 23, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Nov 23, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Nov 23, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
ZauberNerd
added a commit
to xing/act
that referenced
this issue
Nov 24, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Nov 25, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Nov 27, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
ZauberNerd
added a commit
to xing/act
that referenced
this issue
Nov 27, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
ZauberNerd
added a commit
to xing/act
that referenced
this issue
Nov 30, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
ZauberNerd
added a commit
to xing/act
that referenced
this issue
Nov 30, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Nov 30, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Dec 3, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Dec 6, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Dec 6, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
github-actions bot
pushed a commit
to xing/act
that referenced
this issue
Dec 6, 2021
To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes nektos#442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de>
mergify bot
pushed a commit
that referenced
this issue
Dec 8, 2021
* fix: continue jobs + steps after failure To allow proper if expression handling on jobs and steps (like always, success, failure, ...) we need to continue running all executors in the prepared chain. To keep the error handling intact we add an occurred error to the go context and handle it later in the pipeline/chain. Also we add the job result to the needs context to give expressions access to it. The needs object, failure and success functions are split between run context (on jobs) and step context. Closes #442 Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de> * style: correct linter warnings Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de> * fix: job if value defaults to success() As described in the documentation, a default value of "success()" is applied when no "if" value is present on the job. https://docs.github.com/en/actions/learn-github-actions/expressions#job-status-check-functions Co-authored-by: Markus Wolf <mail@markus-wolf.de> * fix: check job needs recursively Ensure job result includes results of previous jobs Co-authored-by: Markus Wolf <markus.wolf@new-work.se> * test: add runner test for job status check functions Co-authored-by: Markus Wolf <markus.wolf@new-work.se> * test: add unit tests for run context if evaluation Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de> * refactor: move if expression evaluation Move if expression evaluation into own function (step context) to better support unit testing. Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de> * test: add unit tests for step context if evaluation Co-authored-by: Markus Wolf <markus.wolf@new-work.se> * fix: handle job error more resilient The job error is not stored in a context map instead of a context added value. Since context values are immutable an added value requires to keep the new context in all cases. This is fragile since it might slip unnoticed to other parts of the code. Storing the error of a job in the context map will make it more stable, since the map is always there and the context of the pipeline is stable for the whole run. * feat: steps should use a default if expression of success() * test: add integration test for if-expressions * chore: disable editorconfig-checker for yaml multiline string Co-authored-by: Björn Brauer <zaubernerd@zaubernerd.de> Co-authored-by: Björn Brauer <bjoern.brauer@new-work.se>
catthehacker
removed
stale-exempt
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For cleaning up the local test environment, we need a way to run commands when the Test job fails. I learned that this could be done using
if: always()in the cleanup steps. I didn't get this to work and thought it might not be supported but found issue #387, which describes my problem, which is closed. I saw that the linked commit, which is supposed to fix this, being in master and therefore build master for testing this. Still, it does not work.Any idea what I may do wrong?
Example (partial):
The text was updated successfully, but these errors were encountered: