Requiring workflows with Repository Rules is generally available!🚢

[tuves]

Just released 🎉 🎉 🎉

Available today, GitHub Enterprise Cloud customers have the ability to set up rules that require workflows to run and pass before a pull request can be merged. This is a powerful new tool for organizations who are creating a centralized ci/cd policy for their repositories. For more detailed information please read our blog announcement and check out our documentation to start requiring workflows.

What's Next?

In the near future we're looking to:

• support additional triggers such as pull_request_target
• support GHES in 3.12

Feedback

We hope you're all as excited as we are and will take some time to share some feedback about this release. All of your feedback helps us improve the feature as we continue to iterate in the coming quarters.

[Palmer-Reed-bah]

This is awesome for any workflow that is non-language-specific. I'd love to see the ability to limit which repos are subject to these required workflows, via repo name pattern, repo topic, or some other criteria

[chrispat]

Stay tuned to the GitHub change log 😉.

[chrispat]

Check out https://github.com/orgs/community/discussions/69914

[ajmalab]

Looking forward to support for additional triggers, would be great to trigger these workflows on PR merge/close events!

[lrotschy]

Thank you for your feedback!

[sbronchard]

Hi !
This feature was greatly expected in our context, but I have troubles to make it work.

I've did it according to the documentation and blog article, but the required workflows are stuck in "Waiting for workflow to run" state.

Ruleset settings

• Enforcement status : Active

• Bypass list : Repo Admin

• Target repositories : The test repository I've selected

• Target branches : Default

• Protection :

  • Restrict Deletions
  • Block force Push
  • Require workflow to pass before merging
    • Set up a test reusable workflow in an Action visible repository

Reusable workflow

name: Test required workflow

on:
  workflow_call:
   

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - run: echo hello

I can't see anywhere the workflow run.

Did I missed something ?

[claystation]

@lrotschy I understand that part. But because these workflows are in the .github/workflows directory, they will run on PR's in the same repo even though they are not configured trough the ruleset. I am not sure what the best practice is, but one way to avoid this is to place the workflow in another directory (for example the root) so it is not picked up by GH when a PR is created for that repo. But i am not sure that conforms to standards regarding workflows. Any thoughts?

[javierjulio]

We had the same issue but it’s easy to avoid. Add a conditional to each job in the workflow to avoid running on that repository. The following is what we use and works well.

if: {{ github.repository != 'my-org/source-repo' }}

[claystation]

@javierjulio Sounds like the only possible workaround. I will try it out, thanks :). Still feels weird it works this way.

[lrotschy]

Another way to address this is to disable actions in the source repo. Go to repo level settings > Actions > General and disable Actions. Your ruleset workflows should still run in the target repos, but not in the source repo. The downside to this approach is that all actions are disabled.

[elbrenn]

Alternately you can disable just the individual workflow in the source repo, as described in https://docs.github.com/en/actions/using-workflows/disabling-and-enabling-a-workflow

[sbronchard]

Hi @sbronchard, this feature requires a pull_request and/or merge_group trigger in your workflow file. The reusable workflow event workflow_call requires that the workflow is called from another workflow and is not compatible with this feature.

Ooooh that's what I've missed ! Thanks a lot @elbrenn it works 👍

[1natsu172]

@tuves hi.
I was originally using the beta version of the required workflow (not rulesets) in a non-enterprise(Team plan) organization. I tried to use the new required workflow feature within rulesets, which is exclusive to enterprises, but while I could set it up, I couldn't actually execute it.

Is there a roadmap to release this feature to non-enterprise organizations on the Team plan?

[lrotschy]

Unfortunately we do not plan to release this to non-enterprise orgs. Organization Rulesets is an enterprise-only feature.

[1natsu172]

@lrotschy Thank you. That's very disappointing.
In that case, I wish they would make the UI require an upgrade to access it, just like they do with the Rule Insights feature.

As it stands, you can set up Rule Sets even on the Team plan, and there was no alert suggesting an upgrade until you set up one rule set. This is confusing for us users.

A UI that lacks consistency creates confusion and fosters false hopes among us users.

[lrotschy]

Thank you for the feedback! We will look into making that clearer.

[javierjulio]

Previously with the beta, it was possible to have a required workflow (pull_request) that fired on other types like labeled, unlabeled, etc. That seems to have stopped working with the migration to Repository Rulesets, why is that?

Are the following pull_request types not supported for a required workflow through Repository Rulesets?

on:
  pull_request:
    types:
      - opened
      - reopened
      - synchronize # necessary for a Required Workflow to avoid pending status check
      - labeled
      - unlabeled

[javierjulio]

I don't know the details of the bug but from what's stated I can safely say it wasn't fixed. I removed our beta based required workflows yesterday so up until then we've had many required workflows using paths filtering and they worked as expected in conjunction with an empty/inverse workflow for each (documented GitHub technique but later removed) that did nothing so the required PR check would not remain in a pending status.

[omer2500]

We are suffering from this issue too,
we have a workflow that checks the description and title of the pr, and if the user edited the title or the description
nothing is being triggered, why did you choose to listen only to default events? is there any plans to support the other events? like the edited pull request
@lrotschy

[lrotschy]

Sorry for the delayed response. We are considering adding other events and activity types, but it isn't on our immediate road map. We initially focused on supporting default activity types as those are the most relevant for determining PR mergeability. We are listening to customer feedback as we plan work for the next few quarters.

[omer2500]

@lrotschy, Thank you for your response!

I'm hopeful that I can shed light on my use case, which I believe many users encountered in the previous version.

We currently have a workflow that checks both the description and title of a pull request. I aim to implement this across all my repositories (approximately 40 in total). Currently, without the necessary workflow, I'm required to create it in a single location using the "workflow call" event, and then manually call this workflow from all 40 repositories through copy-pasting. all this because there is not support for the updated event so when a user updates his pr title or description.

This is very time consuming and not efficient and the required workflows worked great until you moved them to the ruleset section.

So it would be great if it will be placed higher up on your roadmap :)

Thanks

[lrotschy]

Thank you for that input. It's very helpful! cc @tonyjcamp

[jlehnGIT]

When using Evaluate for the required workflow I like that we can see the insights. What would be nice also is the ability to export the data. Is this on the roadmap? Is this doable today via API calls?

[lrotschy]

There is an API for rule insights. See documentation here. Hope that provides the information you are looking for!

[jlehnGIT]

Thank you for the quick reply and will take a look.

[javierjulio]

We are noticing a strange bug that affects a specific repo for some odd reason. We have a Secrets Detection workflow using Yelp's detect-secrets CLI that we have set on 20+ repos through a Required Workflow, first during the beta and now through a Repository Ruleset. During both stages, the same set of repos was configured. The following image is the bug we run into.

For some reason it's as if the repo is showing a cached version of the PR check for the old required workflow and the new one through the Repository Ruleset shows up as pending. For what it's worth, if I try to view the workflow file from the workflow job that is running, I get a GitHub 500 error, hence why I think this is a bug or data issue. We've migrated the required workflow. The name of the workflow and job remain unchanged. Other repos don't have this issue with a pending status.

Has anyone encountered this? We have 10 required workflows set through Repository Rulesets across 25-30 repos.

[javierjulio]

@elbrenn no sorry, that's wrong. We've migrated and run the required workflow through a Repository Ruleset several times with the latest version. No changes. Again some repos don't show this issue at all with the same required workflow. We've run into again now with another workflow but that repo never had it in its history. This started happening to us today. I noticed that GitHub today changed how it renders the required workflow in the PR check list. It would only show the workflow name "Secrets Detection" in one row but now it shows both the workflow name and jobs as individual rows. It's as if they aren't being associated correctly. Here is another repo that just ran into this after posting that didn't have the issue with multiple PRs until today, all using the same required workflow through a Repository Ruleset, unchanged.

[javierjulio]

@obrie thank you. @elbrenn we were pretty certain this a bug and a change that only started happening today. The issue was not occurring before with many runs on the same workflows.

[elbrenn]

Thanks for this extra info, we are investigating 🔍

[elbrenn]

This bug has been resolved. Affected PRs will need a new push or close/ reopen to get a new run in a good state. Apologies for this break and thank you for reporting

[javierjulio]

Thank you! ❤️

[jonatiao]

Hello,
We use reusable workflow where the workflows are in a different organization.

OrgA (all workflows from my company) <- OrgsX uses all workflows from there.

I just realized the "require workflows to pass before merging" rulesets cannot be created pointing to workflows on a different Org than the one where the ruleset is being created. I mean, if I'm in OrgX I cannot select a repository in OrgA.
Any plans to support this in the future. Because looks counterintuitive that I can use a centralized Org for all my workflows but I cannot choose any workflows there to be used as a ruleset.

:(

Thx

[tonyjcamp]

Hi @jonatiao - thanks for the feedback. We don't have cross org support on our roadmap. Just curious, is there a reason why you chose to centralize your workflows in a separate org? We would love to learn more.

Thanks!

[jonatiao]

Hello @tonyjcamp,
Context: we are a very big company with several teams, sometime doing the same work and using the same tools. The communication is not the best mainly because we are too big. We have several organization units working on different markets. Currently we have at least 22 CI/CD tools because we left everyone act by themselves and each OU to decide how they should work. Chaos ^^

Organizing all workflows in a organization helps, in our experience:
1- Everyone knows where are the workflows.
No more: What's the name of the workflows repo in my Org?
No more: Building workflows without knowing if we already have one that does the very same thing.
2- This Org only have repos for workflows, generic shared workflows stay in a general repo. Org Units specific wf stay in a specific repo owned by a specific team.
We can work together on shared workflows between OU.
3- Everyone in this Org have read access to all wf repos.
Help the learning exp, by looking other ppl examples.
4- Help on team communication. We can mention each other, ask for help and keep a concise documentation.
5- Easier to reuse workflows. I know exactly where are the workflows, I do not need to search and ask around.

All the points mentioned above get lost when we start to separate those wf into its repos in its own organizations. It's easy to control, everyone follows the same patterns... we have centralized documentation, boards... etc

Makes sense? thx! ^^

[tonyjcamp]

Thanks for the added detail @jonatiao!