zeke / semantic-pull-requests

:robot: Let the robots take care of the semantic versioning
https://github.com/apps/semantic-pull-requests
Apache License 2.0
1.24k stars 122 forks source link

org-level commit types #87

Closed jasonkuhrt closed 4 years ago

jasonkuhrt commented 4 years ago

I would like to augment the supported semantic version types at the org level. It is currently only possible at the repo level via config file, correct?

zeke commented 4 years ago

That's correct.

I know @gr2m, @iamhughes, @richardlitt, and @wooorm have all worked on projects to help sync repo configuration across orgs. Any tips, y'all?

RichardLitt commented 4 years ago

I use shell scripts to check the existence of files, as it's normally the easiest, by cloning all of the repos locally. Upload a config file to each repo, or point to a single master file in a .github repo or something similar. :)

jasonkuhrt commented 4 years ago

Is it not possible to enhance the GitHub app to accept settings?

IAmHughes commented 4 years ago

I know @gr2m, @IAmHughes, @RichardLitt, and @wooorm have all worked on projects to help sync repo configuration across orgs. Any tips, y'all?

I started stubbing out a PoC here: https://github.com/IAmHughes/sync-action-workflow-across-org

Unfortunately I haven't had time to go back to it yet after hitting a hurdle with Octokit described here: https://github.com/octokit/rest.js/issues/1656

The plan was for an action that triggers off of a push event, checks if the push contained changes to a whitelist set of workflows, then will create PRs to all the repos in your repo whitelist to update the workflow.

wooorm commented 4 years ago

Not entirely sure how I can help, but here’s a quick intro in my experience: The work I did in this field is github-tools and npm-tools, which is about all the metadata around repos, packages, and orgs: the thing that are not checked in. The scale is that we maintain hundreds of projects in many organizations. The challenge is that (at the time?) GH tooling like actions is always at the repo level, and that there aren’t really hooks to plug into for our cases (e.g. if someone somehow got merge rights), so for us we’re doing a daily cron job to check and fix everything

gr2m commented 4 years ago

I would like to augment the supported semantic version types at the org level

Probot supports owner-wide configuration. Just create a .github repository, and in that repository create the .github/semantic.yml file. Probot will look for that file automatically.

zeke commented 4 years ago

Probot supports owner-wide configuration.

That works out of the box!?

gr2m commented 4 years ago

I think so? If I recall correctly we incorporated the functionality of probot-config into probot core

jasonkuhrt commented 4 years ago

I will try this tomorrow thanks!

jasonkuhrt commented 4 years ago

Created https://github.com/graphql-nexus/.github and trying to test here https://github.com/graphql-nexus/test/pull/1 but not confident with result because even a blatantly incorrect title is showing as a PASS. 🤔

zeke commented 4 years ago

It looks like you have improve listed as an allowable prefix type in your config at https://github.com/graphql-nexus/.github/blob/6016cd69f13fc98f42a95421dbef87d00a7b34af/.github/semantic.yml#L3, and you have a commit with an improve: prefix in this PR: https://github.com/graphql-nexus/test/pull/1

That suggests to me that the config is actually working, asimprove would otherwise not be an allowed prefix.

jasonkuhrt commented 4 years ago

Yeah my bad I was thinking as if the titleOnly option was enabled.

This is awesome thanks everyone!