workflow-conclusion

This action will:

Use the Actions REST API to get the conclusion for each previous job.
- The API call provides the conclusion which is the job status after continue-on-error is applied.
- In addition to jobs, the API call also includes status check results.
Examine each additional conclusion that is provided through the additional-conclusions argument.
Determine a single workflow conclusion based on the API results and arguments.

The action will interpret a wider range of inputs in the additional-conclusions argument than the standard GitHub values of cancelled, skipped, failure and success. This allows using the outcome of a step as well as the output that an action might set.

[cancelled | canceled | cancel] are accepted and interpreted as cancelled
[failure | failing | failed | fail] are accepted and interpreted as failure
[success | passing | passed | pass] are accepted and interpreted as success
[skipped | skip] are accepted and interpreted as skipped

The final workflow conclusion is determined by:

First looking for any Cancelled conclusions and if found the conclusion is set to cancelled
Then looking for any Failed conclusions and if found the conclusion is set to failure
Finally looking for any Successful conclusions and if found the conclusion is set to success
If none of the statuses are found, it will set the workflow conclusion to the fallback value which defaults to skipped

Index

Inputs
Outputs
Usage
Contributing
- Recompiling
- Incrementing the Version
Code of Conduct
License

Inputs

Parameter	Is Required	Description
`github-token`	true	The token used to make API requests
`additional-conclusions`	false	A JSON-parseable array of additional conclusions to consider. See the comments above for accepted values. See the Usage Example below for the correct format. This may be helpful if `continue-on-error` is used on a steps or for actions that provide an output with their own status.
`fallback-conclusion`	false	The fallback conclusion to use when one cannot be determined. Defaults to skipped.

Outputs

Output	Description
`workflow-conclusion`	The workflow conclusion.

Usage

jobs:
  ...
  
  test:
    runs-on: [ubuntu-20.04]
    outputs: 
      test-step-outcome: ${{ steps.test.outcome }}             # Can be: cancelled, skipped, failure, success
      test-check-result: ${{ steps.test_check.test-outcome }}  # Can be:  Failed, Passed
    steps:
      - name: dotnet test with coverage
        id: test
        continue-on-error: true
        run: dotnet test --logger trx --configuration Release /property:CollectCoverage=True /property:CoverletOutputFormat=opencover
      
      - name: Process dotnet test results and create a status check
        id: test_check
        # You may also reference just the major or major.minor version
        uses: im-open/process-dotnet-test-results@v2.2.3
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          
  ...

  update-deployment-board:
    runs-on: [ubuntu-20.04]
    needs: [test, auto-deploy-to-dev]
    if: always()
    steps:
      - uses: im-open/workflow-conclusion@v2.1.3
        id: conclusion
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          # needs.test.outputs.test-step-outcome is step status before continue-on-error is applied.  Could be cancelled, skipped, failure, success.
          # needs.test.outputs.test-check-result is an output of the process-dotnet-test-results action.  Could be Failed or Passed
          additional-conclusions: |
            [
              { "name": "dotnet-test-coverage", "conclusion" : "${{ needs.test.outputs.test-step-outcome }}" }, 
              { "name": "process-test-results", "conclusion" : "${{ needs.test.outputs.test-check-result }}" }
            ]
      
      # Use the workflow conclusion below
      - name: Update Deployment Board
        uses: im-open/update-deployment-board@v1.5.1
        with:
          github-token: ${{ secrets.GITHUB_TOKEN}}
          environment: ${{ github.event.inputs.environment }}
          board-number: 1
          ref: ${{ github.event.inputs.branch-tag-sha }}
          deploy-status: ${{ env.WORKFLOW_CONCLUSION }} # can also use ${{ steps.conclusion.workflow-conclusion }}

Contributing

When creating new PRs please ensure:

For major or minor changes, at least one of the commit messages contains the appropriate +semver: keywords listed under Incrementing the Version.
The action code does not contain sensitive information.

When a pull request is created and there are changes to code-specific files and folders, the build workflow will run and it will recompile the action and push a commit to the branch if the PR author has not done so. The usage examples in the README.md will also be updated with the next version if they have not been updated manually. The following files and folders contain action code and will trigger the automatic updates:

action.yml
package.json
package-lock.json
src/**
dist/**

There may be some instances where the bot does not have permission to push changes back to the branch though so these steps should be done manually for those branches. See Recompiling Manually and Incrementing the Version for more details.

Recompiling Manually

If changes are made to the action's code in this repository, or its dependencies, the action can be re-compiled by running the following command:

# Installs dependencies and bundles the code
npm run build

# Bundle the code (if dependencies are already installed)
npm run bundle

These commands utilize esbuild to bundle the action and its dependencies into a single file located in the dist folder.

Incrementing the Version

Both the build and PR merge workflows will use the strategies below to determine what the next version will be. If the build workflow was not able to automatically update the README.md action examples with the next version, the README.md should be updated manually as part of the PR using that calculated version.

This action uses git-version-lite to examine commit messages to determine whether to perform a major, minor or patch increment on merge. The following table provides the fragment that should be included in a commit message to active different increment strategies.

Increment Type	Commit Message Fragment
major	+semver:breaking
major	+semver:major
minor	+semver:feature
minor	+semver:minor
patch	default increment type, no comment needed

Code of Conduct

This project has adopted the im-open's Code of Conduct.

im-open / workflow-conclusion