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

[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

[staffanf]

Hi, I have exactly the same problem. I have a "PR-title must contain JIRA-ticket" workflow that worked previously in the beta and now is broken.

This seems like a very arbitrary omission that was buried deep in the docs at release.

Supporting additional activity types would be very helpful. Also having some way to actually subscribe and follow to Githubs currently internal roadmap issues would be nice.
Having a more open conversation with your customers might make you release with the right set of features instead of having annoyed customers and/or having to patch additional features afterwards.

[rob-broadley]

Hi I also have this problem. For various resons we have a rule that PR titles must contain the ID of a ticket in the project management system.
To enforce this we need the required workflow to run on edit.

Just like others above, to make this work I have had to create a workflow in every repo which just calls the workflow which does the checks.
This is a real pain to manage with many repos. It is especially frustrating that I first configured it pretty quickly as a required workflow on a rule applied to all repos, only to find that didn't work as expected and it would take much much longer to get working.

[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!

[parm-p]

Running enterprise wide workflow in an enterprise product, it seemed reasonable to group some workflow using global standards ( linting, depencies management, credentials logging...)
We are looking for the same feature, running workflow from a dedicated org in the enterprise.

[ajmalab]

Hi, @tuves . There seems to be a bug with this feature. Enable required workflows org-wide outright prevents first push to new repos. We are able to create a repo, but not even the bypass users/admins are able to push to the main branch from local.
Effectively, the only work-around is the checkout a new branch that's named differently from the org-wide default branch name, and then push your changes, at which point that dummy branch becomes your default branch. And then, you need to checkout another branch with your required default branch name (i.e. main), and then push it up, and get an admin to change your default branch. Unsure if you guys are aware of this already.

[lrotschy]

I took a stab at reproducing this with a workflow imposed on the default branch on all repos and with org admin bypass permissions, and I was able to push a first commit to main on a new repo. Maybe you could give us a little more information about your setup so we can take another look, or open a support ticket so you can provide more details about your org and repo privately.

[andrewring]

It would be very helpful to have a field for description/comments in each ruleset, to allow for some documentation of the scope and intent of the rules. This is particularly valuable when using multiple rulesets which effect the same branches.

[MPV]

Can we please have this feature (requiring workflows) for main / master branch also?

[MPV]

In other words, I'd like to be able to require repositories (that follow a particular ruleset) having a particular workflow for on.push, i.e:

on:
  push:
    branches:
      - master
      - main

[rrundle-dave]

When I went to enable this feature for at the org level, once I selected Add Workflow most all of the repos were not-selectable. There we maybe 4 that were selectable. What causes this and how do I get around that?

And just to verify, If I have a workflow that always runs in repo A, but sends commit statuses back to any PR in repo B, this can require a workflow in repo A to pass before PR in repo B can be merged? If not is status checks needed for that? Cannot find workflow in repo A in status check list.

Thanks.

[elbrenn]

@rrundle-dave can you verify the Actions Permissions in repo A? Are they set to "Accessible from repositories in the ORGANIZATION NAME organization"?

This tip came from: https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/troubleshooting-rules#source-repository-permissions

[rrundle-dave]

@elbrenn That was it!! Thanks so much for responding, and a quick one at that.