Opened 7 months ago

Closed 7 weeks ago

#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

Description

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 7 months ago by teor

Sponsor: Sponsor31-can

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

comment:2 Changed 7 months ago by teor

Keywords: fast-fix added

comment:3 Changed 5 months ago by nickm

Keywords: 041-deferred-20190530 added

Marking these tickets as deferred from 041.

comment:4 Changed 5 months ago by nickm

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

comment:5 Changed 2 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 2 months ago by teor

Status: assignedneeds_review

See my pull request:
https://github.com/torproject/tor/pull/1215

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

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

Questions:

  • 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 2 months ago by teor (previous) (diff)

comment:7 Changed 2 months ago by asn

Reviewer: dgoulet

comment:8 Changed 2 months ago by asn

Reviewer: dgouletasn

comment:9 Changed 2 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 2 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.

Please don't push this unless #31314 is also in merge_ready.

Last edited 2 months ago by asn (previous) (diff)

comment:11 Changed 8 weeks 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 7 weeks 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 7 weeks ago by teor

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