Enabling separate workflows for private repository

[Zenious]

Is your feature request related to a problem?

In the mirrored private repository, we would like to inject a separate set of GitHub Workflows that perform internal checks and follow the organisation’s approval process. Examples of these changes include updating workflow runners from GitHub‑hosted to self‑hosted, enforcing the use of specific action versions approved by the organisation, or running additional SecOps tools as part of the workflow.

The mirrored repository should not execute certain workflows that exist in the public repository—for example, workflows related to releases—since they are not relevant or appropriate for the mirrored environment.

These injected workflows need to be present in the default branch because:

• Developers create their feature branches from the default branch, so it is important that the correct workflows are propagated into their branches.
• When a pull request is opened against the default branch, the internal‑check workflows must run to serve as a gate before any code is merged.

This ensures that organisational requirements are consistently applied across all development and merge activities.

Describe the solution you'd like

I would like the ability to define different sets of workflows for different types of repositories, as each repository may require a unique workflow configuration. Additionally, there should be an option to specify files or paths that should be excluded when syncing changes from the mirror repository to the forked repository, ensuring that certain local or repository‑specific files are not overwritten.

Describe alternatives you've considered

One alternative is to place the workflow changes on non‑default branches. However, this approach is not intuitive for developers, as they typically branch from the default branch. This makes it easy for required organisational workflows to be missed or inconsistently applied.

Additional context

No response

[riley-kohler]

Unfortunately I think that injecting workflows on an individual fork or mirror would require adding a commit which would break the ability for private mirrors to sync commits between the mirror and the fork without inserting an undesirable commit. The way that I would suggest handling these internal checks is by configuring them organization wide on the private org that contains your mirrors. My team accomplishes this by adding GitHub check functionality to the app that we are using for private-mirrors. Webhooks are sent from the GitHub app to a forwarder lambda that sends the necessary webhooks to our private mirrors endpoint and those needed for checks to a separate lambda that handles running the checks. There may be a way to create an org wide GitHub action workflow as well in the .github repo on your org but I'm not entirely sure.

[Zenious]

Thanks @riley-kohler for your insights. We will be exploring the route of leveraging on organisation ruleset to execute action workflows. Although, this would likely means that we wont be able run any workflow on push event as action workflows will only be executed on PR event when going down the organisation ruleset route. The trade‑off is that this approach would let us avoid running or maintaining an additional application alongside PMA.

[ahpook]

@Zenious Sounds like you got a suitable workaround - is it OK to close this issue?

[Zenious]

Hi @ahpook, we are good to close this issue! Thanks @riley-kohler for sharing how your team handles this similar situation!