fix: preserve "always" condition for artifacts in conditional steps

[Copilot]

Pull request description

This PR ensures that artifacts maintain their "always" condition and are not overwritten with the parent step's condition during workflow processing. This is a design improvement to ensure artifacts can be uploaded regardless of step execution status.

Note: While this change improves the condition handling for artifacts, it does not fully address the root cause reported in issue #6817, where both shell commands and artifacts are skipped when env.TEST="true". The original issue suggests a runtime condition evaluation problem that requires further investigation beyond the scope of this PR.

# With this fix: artifacts will have "always" condition at build time
steps:
  - condition: env.TEST
    shell: echo "test"
    artifacts:
      paths: ["*.xml"]

The ProcessArtifacts operation sets condition: "always" explicitly to ensure artifacts run regardless of step success/failure, but the processor was previously overwriting it with the parent step's condition.

Checklist (choose whats happened)

• tested locally
• added a test

Breaking changes

Changes

• Modified pkg/testworkflows/testworkflowprocessor/processor.go to preserve "always" condition when set by operations
• Added test case TestProcessArtifactsWithStepCondition validating that artifacts maintain "always" condition (simplified to "true") while other operations inherit step condition
• Added clarifying comments explaining test scope and limitations

Fixes

• Artifacts now preserve their "always" condition instead of inheriting the step's condition
• Partially addresses Incorrect evaluation of test step condition #6817 (further investigation needed for runtime evaluation issue)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Incorrect evaluation of test step condition</issue_title>
<issue_description>Describe the bug

The test workflow step condition is incorrectly evaluated as skipped when the step contains definitions of artifacts.

To Reproduce

apiVersion: testworkflows.testkube.io/v1
kind: TestWorkflow
metadata:
  name: test1
spec:
  container:
    env:
      - name: TEST
        value: "true"
  steps:
    - condition: env.TEST
      shell: echo "test"

test1 works fine and its execution produce

Context:  (2.2.5)   Namespace: testkube
---------------------------------------
Test Workflow Execution:
Name:                 test1
Execution ID:         690cf0cd0722f9954ad13e2f
Execution name:       test1-1

Creating state... done
Initializing state... done
Configuring init process... skipped
Configuring toolkit... skipped
Configuring shell... skipped

• passed in 1.224s

• (1/1) Run shell command
test

• passed in 16ms

test workflow execution completed with success in 1.339845561s 🥇

but when the step contains definition for artifacts

apiVersion: testworkflows.testkube.io/v1
kind: TestWorkflow
metadata:
  name: test2
spec:
  container:
    env:
      - name: TEST
        value: "true"
  steps:
    - condition: env.TEST
      shell: echo "test"
      artifacts:
        paths:
          - "*.xml"

the step condition is evaluated as skipped

Context:  (2.2.5)   Namespace: testkube
---------------------------------------
Test Workflow Execution:
Name:                 test2
Execution ID:         690cf2780722f9954ad13e4a
Execution name:       test2-1

Creating state... done
Initializing state... done
Configuring init process... skipped
Configuring toolkit... skipped
Configuring shell... skipped

• passed in 1.624s

• (1/2) Run shell command
• skipped

• (2/2) Upload artifacts
• skipped

test workflow execution completed with success in 1.87274512s 🥇

Version / Cluster

testkube version: 2.1.166 (standalone agent)
kubernetes version: eks 1.33</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Incorrect evaluation of test step condition #6817

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[olensmar]

@copilot
But in the above example why is ProcessArtifacts operation skipped, when parent condition is true

apiVersion: testworkflows.testkube.io/v1
kind: TestWorkflow
metadata:
  name: test2
spec:
  container:
    env:
      name: TEST
      value: "true"
  steps:
    condition: env.TEST
    shell: echo "test"
    artifacts:
      paths:
        - "*.xml"

[Copilot]

@copilot
But in the above example why is ProcessArtifacts operation skipped, when paremt condition is true

...

You're absolutely right to question this. Looking at the issue more carefully, I realize my fix addressed the wrong problem.

The original issue shows that when TEST="true", BOTH the shell command and artifacts are skipped. This means the condition env.TEST is somehow evaluating to false (or the entire group is being skipped) when artifacts are present, which shouldn't happen.

My fix was ensuring artifacts have an "always" condition instead of inheriting the step condition, but this doesn't explain why the original issue occurred where both operations were skipped despite TEST being "true".

I need to investigate why adding artifacts to a step causes the condition evaluation to fail. This might be a different bug in the flattening logic or action processing. Let me dig deeper into this.

@copilot
But in the above example why is ProcessArtifacts operation skipped, when parent condition is true

...

You're absolutely right to question this. Looking at the issue more carefully, I realize my fix addressed the wrong problem.

The original issue shows that when TEST="true", BOTH the shell command and artifacts are skipped. This means the condition env.TEST is somehow evaluating to false (or the entire group is being skipped) when artifacts are present, which shouldn't happen.

My fix was ensuring artifacts have an "always" condition instead of inheriting the step condition, but this doesn't explain why the original issue occurred where both operations were skipped despite TEST being "true".

I need to investigate why adding artifacts to a step causes the condition evaluation to fail. This might be a different bug in the flattening logic or action processing. Let me dig deeper into this.