Stay tuned to the GitHub change log 😉.

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

Thank you for your feedback!

+1 we would love use push events for things like notifications/logging enforced and shared across a GitHub enterprise organization, would significantly cut down on duplication and maintenance

Nice 👍

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' }}

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

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.

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

Nice 👍

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

@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.

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

Nice 👍

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.

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.

Thank you for your feedback. I will bring this to the attention of our product team.

Nice 👍

I too am trying to enforce PR title hygiene to include workitem or incident ticket IDs. Requiring a workflow with a ruleset at the organization level works perfectly on the happy-path. However, relying on the default triggers introduces a lot of friction when developers forget to include a ticket during PR creation. Training developers to push new commits or close and reopen a PR to re-validate the ticket title doesn't align with how any of our other pre-submit CICD checks work (comments, labels, or it-just-works).

Triggering required workflows on the pull_request and pull_request_target events edit, labeled, and unlabeled would bring this feature into parity with other solutions we've explored.

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

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

Nice 👍

@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.

Thanks for this extra info, we are investigating 🔍

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

Thank you! ❤️

Nice 👍

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

Thanks for the added detail @jonatiao!

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.

We are using a GHES installation and are having the exact same requirements.
This feature would be very helpful to enforce certain criteria to achieve audit compliance.

Nice 👍

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.

Nice 👍

Nice 👍

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

Thank you for your feedback. I will bring this to the attention of our product team.

Is there any update on this feature request? This would be extremely valuable, and without this the value of repository rulesets is substantially limited for our use cases.

Hi @lrotschy - Would you be able to share if there has been any progress on bringing this in please?

This would greatly help with our Security workflows i.e. triggering scans on push to main to get an accurate representation of vulnerabilities in the live app

Thanks

@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

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

We do not currently support non-default activity types (see more info in the troubleshooting docs), but it is on our radar.

Yep, this is on our list. It's not in the next 3 months and I don't want to talk about anything beyond that as the world could change by then :) but doing repo level is on the backlog <3