#29879 closed enhancement (fixed)

Make git-push-all.sh push branches in a specific order

Reported by: teor Owned by: teor
Priority: Medium Milestone: Tor: 0.4.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-ci, git-scripts, fast-fix, 041-deferred-20190530
Cc: gaba Actual Points: 0.2
Parent ID: #31178 Points: 0.1
Reviewer: asn Sponsor: Sponsor31-must


git-push-all.sh currently pushes all the branches at once. Then GitHub sends requests to build each branch to Travis and Appveyor.

Depending on the exact order of the push and network requests, branches are built in an arbitrary order.

Ideally, we want to push branches in this order:

  • master
    • practracker errors
    • errors that appear when merging backports to a later release
  • maint branches, in order from the earliest release, to the most recent release
    • errors that appear when merging the PR into code that was added after the PR merge was build
  • release branches, in the same order

So we should push branches in a for loop, with a sleep between each branch. On high-latency networks (me!), the sleep might need to be a few seconds long.

Child Tickets

Change History (13)

comment:1 Changed 17 months ago by teor

Sponsor: Sponsor31-can

This issue was partly caused by practracker, marking as Sponsor 31 can.

comment:2 Changed 17 months ago by teor

Keywords: fast-fix added

comment:3 Changed 15 months ago by nickm

Keywords: 041-deferred-20190530 added

Marking these tickets as deferred from 041.

comment:4 Changed 15 months ago by nickm

Milestone: Tor: 0.4.1.x-finalTor: 0.4.2.x-final

comment:5 Changed 12 months ago by teor

Actual Points: 0.2
Keywords: git-scripts added; tor-merge-scripts removed
Milestone: Tor: 0.4.2.x-finalTor: 0.4.3.x-final
Owner: set to teor
Status: newassigned

I did this change because I needed it to test the backports of #30213, #29280, and #30591 in a sensible order.

comment:6 Changed 12 months ago by teor

Status: assignedneeds_review

See my pull request:

When TOR_PUSH_DELAY is greater than zero, the branch pushes and CI jobs run in this order:
release-* (in arbitrary order)

I also made push --atomic the default, and passed any script arguments to git push.


  • should "no delay" be the default?

The CI jobs will launch in an arbitrary order by default, but the push will be quick. I think that's a good default for most mergers, who are usually only pushing 1-3 changed branches (master and alpha).

Last edited 12 months ago by teor (previous) (diff)

comment:7 Changed 12 months ago by asn

Reviewer: dgoulet

comment:8 Changed 12 months ago by asn

Reviewer: dgouletasn

comment:9 Changed 12 months ago by teor

Cc: gaba added
Milestone: Tor: 0.4.3.x-finalTor: 0.4.2.x-final
Parent ID: #31178
Sponsor: Sponsor31-canSponsor31-must

Gaba, this ticket is also part of #31178.

comment:10 Changed 12 months ago by asn

Status: needs_reviewmerge_ready

LGTM! That's a good one.

I didn't find a way to test this because I didn't have any backports to push, but I played a bit with the --dry-run and turning the git-push into echos and it seems to work OK.

Version 0, edited 12 months ago by asn (next)

comment:11 Changed 12 months ago by nickm

Oh crud! I merged it before I read the note on the last sentence. Please let me know what steps to take.

comment:12 Changed 12 months ago by teor

The extra features are contained behind extra flags or env vars, so I don't think there is any need to do anything.

Feel free to test it next time you merge and push a backport.

#31463 is a CI backport that we can backport immediately.

comment:13 Changed 12 months ago by teor

Resolution: fixed
Status: merge_readyclosed
Note: See TracTickets for help on using tickets.