Closed Bug 779752 Opened 13 years ago Closed 13 years ago

Adjust TBPL push to prod script so it outputs the list of changesets/files in the push

Categories

(Infrastructure & Operations Graveyard :: WebOps: Other, task, P4)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: emorley, Assigned: dmaher)

Details

(Whiteboard: [triaged 20120910][push-interrupt][sheriff-want])

For an example of the current script output, see bug 779658 comment 1. In that instance, another changeset was pushed to prod along with bhearsum's needed fix (which wasn't a problem, since we wanted the other fix at some point), but it would be good if this was clearer in the output, so bhearsum would have known to close the other bug. As such, please may we use -v on the |hg update| to list the files changed, and also have a list of the changesets affected by hg update. For the latter, it would seem that it isn't possible to get hg update to list the changesets itself, so we'd need to do something like an hg log between the working directory revision and the changeset we're updating to. However, after playing around with this, the closest I got using revsets was: $ hg log -r .::<changeset_target> --template '{node|short} | {desc|firstline}\n' ...which listed the current working directory changeset as well, not just the descendents of it. I guess a simper alternative is just to switch the script from doing: hg pull hg update -r <cset> to hg incoming -r <cset> --template '{node|short} | {desc|firstline}\n' hg pull -r <cset> -u -v That way we let hg incoming do the hard work. With this solution, we can also remove the |hg parent| line (added by bug 758197), since we'd never end up in a situation where the working directory != repo tip. (Btw not urgent, can sit for a few weeks if needs be :-))
(In reply to Ed Morley [:edmorley] from comment #0) > With this solution, we can also remove the |hg parent| line (added by bug > 758197), since we'd never end up in a situation where the working directory > != repo tip. Thinking about it, we'd probably want that left in as well, so that the cron job output for the 'no changes found' case still has a record of what changeset we're at, for https://tbpl-dev.allizom.org/cache/revision_info.txt - especially given that the update has been known to get stuck.
Whiteboard: [sheriff-want]
I'll update this on dev first, then prod.
Assignee: server-ops-devservices → shyam
Going to toss this over to Webops, they'll probably get to this faster than I can at this point :|
Assignee: shyam → server-ops-webops
Component: Server Operations: Developer Services → Server Operations: Web Operations
QA Contact: shyam → cshields
Severity: enhancement → normal
Priority: -- → P4
Whiteboard: [sheriff-want] → [triaged 20120910][push-interrupt][sheriff-want]
Assignee: server-ops-webops → dmaher
Status: NEW → ASSIGNED
Hello, I have made the modifications to the push script as outlined above. For reference, the meat of the update script is (now) as follows : cd $CODE_DIR hg incoming -r $CSET --template '{node|short} | {desc|firstline}\n' hg pull -r $CSET -u -v cd $CODE_DIR hg parent Sorry for the delay on getting to this bug. If you have any further comments or concerns, please don't hesitate to let us know. Have a nice day !
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Looks perfect, thank you (example in bug 821491 comment 1) :-)
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.