needs.<job id>.result is using steps conclusion instead of outcome

[tleveque69]

Thank you 🙇‍♀ for wanting to create an issue in this repository. Before you do, please ensure you are filing the issue in the right place. Issues should only be opened on if the issue relates to code in this repository.

• If you have found a security issue please submit it here
• If you have questions about writing workflows or action files, then please visit the GitHub Community Forum's Actions Board
• If you are having an issue or question about GitHub Actions then please contact customer support

If your issue is relevant to this repository, please include the information below:

Describe the bug I've been trying to use needs context However if ever your job has continue on error flag set to true and you check the job result via the needs context you'll get success while the job actually fails

To Reproduce Steps to reproduce the behavior:

1. Create a failing jobs with continue-on-error set to true
2. Create another job needing the first one and try to access the first job result

Expected behavior Expected needs.job1.result to be failure even if flag continue-on-error is set to true

name: Test download Input
on:
  push:
      branches:    
      - master
jobs:
  job1:
    runs-on: ubuntu-latest
    continue-on-error: true
    steps:
      - name: "Check if artifact has already been built"
        id: dwnld
        uses: actions/download-artifact@v2
        with:
          name: ${{ steps.get-commit.outputs.commit }}_${{ matrix.apps }}
      - name: The job has failed
        if: ${{ failure() }}
        run: echo fails
  build_artifact:
    runs-on: ubuntu-latest
    needs: [job1]
    steps:
      - run: echo ${{ needs.job1.result }}

[maxisam]

Any update on this issue? It has been a while. This thing break my use case. Now I can't use status for branch protection.

##Update

I did more test on this. I think it only happens in certain edge cases. In general, it still work as expected.

https://github.com/maxisam/create-summary-check-status/actions/runs/1885906626

However, I did have a weird case that it doesn't work like it should.

[ldaneliukas]

@maxisam I just happened to stumble upon this as I've experienced the same issue. What did you mean that this is an edge case? I reproduced it with:

name: Test

on: push

jobs:
  job1:
    runs-on: ubuntu-latest
    continue-on-error: true
    steps:
      - run: exit 1

  job2:
    runs-on: ubuntu-latest
    needs: job1
    if: needs.job1.result == 'success'
    steps:
      - run: echo ${{needs.validate.result}}

Both jobs always run, because job1 result is always seen as success even though it is failed and marked as such in the UI.

Does not seem like an edge case 🤔

[cfoch]

@ldaneliukas any workaround for your mentioned case? The only idea for now is defining an output on job1, and checking for that output on job if condition.

[ldaneliukas]

@ldaneliukas any workaround for your mentioned case? The only idea for now is defining an output on job1, and checking for that output on job if condition.

No, not really and there doesn't seem to be any response to this, so we just live with it (i.e. we don't use this 'feature').

[wburgess-sdx]

In the docs it says job.<job_id>.result is only for reusable workflows 👎 :

The jobs context is only available in reusable workflows, and can only be used to set outputs for a reusable workflow. For more information, see "Reusing workflows."