| Message ID | a4c6f687c0a8ce55863a19a1c4048438f02803b5.1588695295.git.congdanhqx@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Provide option to opt in/out GitHub Actions | expand |
On Tue, May 05, 2020 at 11:26:40PM +0700, Đoàn Trần Công Danh wrote: > -on: [push, pull_request] > +on: > + pull_request: > + push: > + branches: > + - maint > + - master > + - next > + - jch > + - pu > + - 'for-ci**' Should this be "for-ci/**", or are we intending for "for-ci-foo" to work? I'd suspect anybody who uses this would use a full directory namespace in a refspec (like "refs/heads/*:refs/heads/for-ci/*"). It might be simpler conceptually to only support that. > + tags: > + - '**' > + - '!**wip**' IMHO this "wip" match is going too far. That was the name in the example I used, but really it could have been anything. I think we should either: - just build all tags; it usually takes special effort to push them up anyway, so a one-off "just mark this spot" tag likely wouldn't get pushed anyway - just build v[0-9]*, which would catch actual releases -Peff
On 2020-05-05 12:51:25-0400, Jeff King <peff@peff.net> wrote: > On Tue, May 05, 2020 at 11:26:40PM +0700, Đoàn Trần Công Danh wrote: > > > -on: [push, pull_request] > > +on: > > + pull_request: > > + push: > > + branches: > > + - maint > > + - master > > + - next > > + - jch > > + - pu > > + - 'for-ci**' > > Should this be "for-ci/**", or are we intending for "for-ci-foo" to > work? I'd suspect anybody who uses this would use a full directory > namespace in a refspec (like "refs/heads/*:refs/heads/for-ci/*"). It > might be simpler conceptually to only support that. I made this because I saw someone mentioned that they would like to push to 'for-ci' and expect it works for them. I guess it may be better to have: - for-ci - for-ci/** > > > + tags: > > + - '**' > > + - '!**wip**' > > IMHO this "wip" match is going too far. That was the name in the example > I used, but really it could have been anything. I think we should > either: > > - just build all tags; it usually takes special effort to push them up > anyway, so a one-off "just mark this spot" tag likely wouldn't get > pushed anyway > > - just build v[0-9]*, which would catch actual releases This sounds better, just build "v[0-9]*" and ignore everything else, with this pattern, I think we don't need to advertise tag to our users. And our maintainer shouldn't worry about it, since our maintainer will (likely) only push v[0-9]* tagged code, anyway.
On Wed, May 06, 2020 at 12:05:46AM +0700, Đoàn Trần Công Danh wrote: > > Should this be "for-ci/**", or are we intending for "for-ci-foo" to > > work? I'd suspect anybody who uses this would use a full directory > > namespace in a refspec (like "refs/heads/*:refs/heads/for-ci/*"). It > > might be simpler conceptually to only support that. > > I made this because I saw someone mentioned that they would like to > push to 'for-ci' and expect it works for them. > > I guess it may be better to have: > > - for-ci > - for-ci/** Ah, that makes sense. Yeah, the double-rule looks fine to me, but understanding that use, the original "for-ci**" is OK to me, too. -Peff
Đoàn Trần Công Danh <congdanhqx@gmail.com> writes: > Git's maintainer usually don't have enough time to debug the failure of > invidual feature branch, they usually want to look at intergration > branches only. Please please please do not make this thing about me. I do not have Actions enabled at https://github.com/gitster/git/ repository anyway. Instead, please focus on making the end result useful for general contributors. > Contributors now can have GitHub Actions as an opt-in option, > should they want to check their code, they will push into designated > branch. OK, so this is an opt-in approach as you outlined in the cover letter. > + pull_request: > + push: > + branches: > + - maint > + - master > + - next > + - jch > + - pu > + - 'for-ci**' > + tags: > + - '**' > + - '!**wip**' I agree with the agreement you and Peff reached about for-ci plus for-ci/** patterns and building only v[0-9] tags in your discussion downthread. Thaks.
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index fd4df939b5..9bba0ce068 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -1,6 +1,18 @@ name: CI/PR -on: [push, pull_request] +on: + pull_request: + push: + branches: + - maint + - master + - next + - jch + - pu + - 'for-ci**' + tags: + - '**' + - '!**wip**' env: DEVELOPER: 1 diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 8686318550..e516b080df 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -79,7 +79,8 @@ test your changes on Linux, Mac (and hopefully soon Windows). See GitHub-Travis CI hints section for details. Alternately, you can use GitHub Actions (which supports testing your changes -on Linux, macOS, and Windows) by pushing into a branch in your fork +on Linux, macOS, and Windows) by pushing into a branch whose name starts +with "for-ci", or a tag whose name doesn't have `wip`, or opening a GitHub's Pull Request against https://github.com/git/git.git or a fork of that repository.
Git's maintainer usually don't have enough time to debug the failure of invidual feature branch, they usually want to look at intergration branches only. Contributors now can have GitHub Actions as an opt-in option, should they want to check their code, they will push into designated branch. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> --- .github/workflows/main.yml | 14 +++++++++++++- Documentation/SubmittingPatches | 3 ++- 2 files changed, 15 insertions(+), 2 deletions(-)