You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Require Git tests to have passed before being able to send to the mailing list #16
As another precondition, in addition to sending the patch mail to yourself for review before sending it to the mailing list, it would be nice if submitgit would require the Git tests to have passed.
For this to work, the git/git project at GitHub would need to integrate e.g. with Travis CI (some work for this already seems to be done here) and submitgit would only enable the "Send" button on "The Mailing List" tab if CI reports Git to build and test fine.
This would be particularly useful for people like me who work on a fork of Git for other OSes than Linux (in my case it's the Windows fork) to check whether tests also still pass on Linux.
Yep, this would be lovely. As you say, it's dependent on the git/git project at GitHub integrating with something like Travis CI - once that's done (which would be brilliant) I'd be happy to add this precondition to submitGit.
If I heard correctly, integration with Travis has to give way more than read permission to the repository to the third-party that runs test, no? I do not care what individual developers allow to be done to their copy of git.git, but if the proposal under discussion involves granting new permissions on git/git to third parties, I would be very negative. I'd probably have to stop pushing into the repository and drop that from the list of my "these are the repositories you can get official copy of Git".
If I heard correctly, integration with Travis has to give way more than read permission to the repository to the third-party that runs test, no?
Actually, it works without the huge extended permission set - all Travis really needs is read access and a prod from a GitHub webhook to start it's build - but the default admin tool makes you grant extensive permissions in order for them to be able to set up that webhook for you. If you set up the webhook yourself, you don't need to grant the permissions.
The webhook looks like this:
...you get the token from the Travis admin console.
Activity
rtyley commentedon Jul 9, 2015
Yep, this would be lovely. As you say, it's dependent on the git/git project at GitHub integrating with something like Travis CI - once that's done (which would be brilliant) I'd be happy to add this precondition to submitGit.
sschuberth commentedon Jul 9, 2015
I'd be curious whether @gitster would even be in favor of adding Travis CI
.ymlfile?gitster commentedon Jul 9, 2015
If I heard correctly, integration with Travis has to give way more than read permission to the repository to the third-party that runs test, no? I do not care what individual developers allow to be done to their copy of git.git, but if the proposal under discussion involves granting new permissions on git/git to third parties, I would be very negative. I'd probably have to stop pushing into the repository and drop that from the list of my "these are the repositories you can get official copy of Git".
rtyley commentedon Jul 9, 2015
Actually, it works without the huge extended permission set - all Travis really needs is read access and a prod from a GitHub webhook to start it's build - but the default admin tool makes you grant extensive permissions in order for them to be able to set up that webhook for you. If you set up the webhook yourself, you don't need to grant the permissions.
The webhook looks like this:
...you get the token from the Travis admin console.
rtyley commentedon Jul 10, 2015
A few more details on the extended permission set Travis uses:
http://docs.travis-ci.com/user/github-oauth-scopes/