Required workflows should have a less strict run mode

[fproulx-boostsecurity]

Select Topic Area

Product Feedback

Body

I have tested a bit and it appears that Required workflows effectively means Required statuses, which makes sense conceptually, but that might be a little too strict. For instance, I would like to apply a workflow to scan using a certain tool across all repositories, but I don't necessarily want this to be Required status, it could soft-fail / fail-open in some situations and I would be ok. Like run as best effort.

[reiniertimmer]

I was thinking the same thing. Having everything as required makes sense for some, but not all use cases.

Now it seems that is actually possible to have required and non-required status checks, but according to the documentation, it depends on the branch name

This feels like a bit of an odd limitation

[Moser-ss]

I had the same feeling after I did my tests. When I read about this new feature, I thought, "yeah, a feature that allows me to add all the necessary Workflows without creating a new workflow in each repo". But then I saw this is more a way to create required status at the org level.

it will be nice to use the same mechanics but add organizational workflows, like a workflow to deploy a service

[juozasget]

I'd love if this functionality provided a toggle to turn the required checks on/off.

Currently I'm more interested in the ability to globally set workflows to run on all repositories from a central repository without setting any required checks. That would eliminate a lot of boiler plate code that we are pushing across hundreds of repositories.

Having the required checks set breaks a lot of such actions.

Example:

1. We want to run a Jira automation workflow on all repositories that automatically moves tickets to done if a PR is merged to master with a Jira ticket number in the title. If we enable this via required workflows - the required checks would not allow us to merge the PR. But the workflow is intended to run after the merge.

[chejn]

Adding to this,

It would be great to be able to run workflows for existing and new repositories without having to configure it one by one, without it being limited to required checks.

[e3b0c442]

Also have use cases for being able to apply workflows to multiple repos in an org without making it a "required" check. Pretty please, GitHub :)

[reiniertimmer]

As an addition, all jobs inside a required workflow are made required (even if they don't run).

So, for example, when you have a workflow that consists of multiple jobs like this:

jobs:
  required:
    runs-on: ubuntu-latest
    steps:
      - run: echo "second step"
  optional:
    runs-on: ubuntu-latest
    if: ${{ some.condition }}
    steps:
      - run: echo "optional step"

But both jobs are marked as required

[reiniertimmer]

And something else that would benefit from a setting to make checks optional is support for different types on: pull_request. These can be supplied in the workflow and it will work actually:

on:
  pull_request:
    types: [opened]

and

on:
  pull_request:
    types: [closed]

However, as expected, the types: [opened] only works on the first check run of a PR. If an additional commit takes place, then the workflow will not run. For types: [opened] the check will never run.

First run

Additional runs

[lars-reimann]

The distinction between organization-wide required workflows and checks that are marked as required using a branch-protection rule is also confusing. Take this picture for example:

build-api-editor is a job defined in the repo and the corresponding check is then marked as required using a branch-protection rule. It has the (Required) tag. The other two are organization-wide required workflows. They also have the (Required) tag. However, an admin is able to bypass the build-api-editor check but not the others. At the very least they should be marked differently.

I also don't like that required workflows now force the creation of pull requests for everyone, no exceptions, disregarding the settings in the branch-protection rules of the repo.

Ideally I want something like this:

• In the organization settings: Select workflows that are always run for all repos.
• In the repo settings: Using normal branch-protection rules, configure which of these workflows are required. They should respect all other settings in the branch-protection rules, like whether specific users can push directly to the protected branch.

Bonus:

• In the organization settings: Have the current behavior to make the checks required, but as an option for each workflow. Show them with another tag in the checks list, though, like (Required by Organization).

Personally, I could live very well without the bonus, though, since branch-protection rules are needed anyway in each repo and being able to configure in a central place which workflows get run would be by far the largest benefit of this feature.

[bewuethr]

To add another scenario where the strictness is an annoyance: we have some automation that updates documentation and indices, triggered on pushes into the default branch.

With required workflows, this automation can't push commits directly to the default branch any longer, not even with a personal access token with repo admin permissions:

remote: error: GH006: Protected branch update failed for refs/heads/main.

seems to override all permissions.

It might be possible to work around this by creating PRs and have them approved and merged with Actions, but that would defeat the purpose of required workflows making configuration simpler by not requiring per-repo changes.

[lars-reimann]

Same issue for me: I was previously using @semantic-release/git to push an updated changelog, which is no longer possible.

I don't want to configure the workflows in each repo again, so for now I'm using semantic-release-github-pullrequest instead to create a pull request, which works fine since I trigger releases manually and rarely and the repos are not too busy. But in cases where releases happen frequently, this solution has too much overhead to be workable.

[ViacheslavKudinov]

Same concern from my side.
We need another type of workflows which can be configured by Org owners to run for certain repositories, but do not have them as required.
They shouldn't block ability to merge even if they failed for some reason.

Definitely we can use Webhooks, GH apps and API to do something similar as alternative way, but it requires more efforts and maintenance of a "solution".

[ashokirla]

Hi 👋 ,

Thanks for the feedback. We are currently working of few features that should address your concerns.

1. Ability to run required workflows without enforcing the blocking of PR merge.
2. Give option to override the PR merge to a specific set of roles.

Thanks

[chejn]

Hi 👋 ,

Thanks for the feedback. We are currently working of few features that should address your concerns.

1. Ability to run required workflows without enforcing the blocking of PR merge.
2. Give option to override the PR merge to a specific set of roles.

Thanks

Will there be a change allowing required workflows to run workflows from another organisation? If so this would be great

[chejn]

Hi 👋 ,

Thanks for the feedback. We are currently working of few features that should address your concerns.

1. Ability to run required workflows without enforcing the blocking of PR merge.
2. Give option to override the PR merge to a specific set of roles.

Thanks

Is there an ETA for this ?

[tonyjcamp]

Hi @chejn! Thanks for reaching out! We’re still currently working on:

1. Ability to run required workflows without enforcing the blocking of PR merge.
2. Give option to override the PR merge to a specific set of roles.

We don’t have a date ready to share yet but we are actively working on these items.

Also, thank you for the suggestion to allow required workflows to run workflows from another organisation. We don’t have any plans to start on this project yet but we will keep it in consideration. Thank you!