Opened 7 years ago

Last modified 6 years ago

#2490 new enhancement

scheduler that remembers last-seen revisions for each codebase

Reported by: thedylman Owned by:
Priority: major Milestone: 0.9.+
Version: 0.8.7p1 Keywords:
Cc: ian.pozella@…


The setup is:

Builder Y with mercurial repos A and B. SingleBranchScheduler? with codebases for A and B.

The steps:

Commit with id 5 to repo A. After treeStableTimer finishes build is queued on builder Y and waiting for slave. Commit with id 3 to repo B. Builder Y starts build/clone step with change for repo A and head for repo B.

The problem is repo B is updating to head because revision id is set to None. Instead it should update to the revision id 2 from the previous build on builder Y.

In a single repo setup the sourcestamp always has a change so it updates to the revision id of that change. For a multirepo setup only repos with changes have the revision field set, so all other repos are updated to head which then includes changes that are not listed in the sourcestamps.

The effects of this is the web interface and emails do not show the correct changes and users for a build.

Change History (6)

comment:1 Changed 7 years ago by dustin

  • Keywords schedulers removed
  • Milestone changed from 0.8.8 to 0.8.+
  • Summary changed from Scheduler build clones head instead of revision from previous build in multi-repo setup to scheduler that remembers last-seen revisions for each codebase
  • Type changed from defect to enhancement

The SingleBranchScheduler doesn't support this behavior. It can either use the latest revision or, by customizing the codebases parameter, fix a revision, branch, etc.

It might be nice for a *different* scheduler to support this kind of "remember the last revision I saw" behavior.

comment:2 Changed 7 years ago by Ham022

  • Cc ian.pozella@… added

comment:3 Changed 7 years ago by thedylman

What name should I use for this single branch scheduler with last-seen per codebase?

  1. SingleBranchLastSeenScheduler
  2. SingleBranchMultRepoScheduler
  3. SingleBranchScheduler with optional argument useLastSeen
  4. Something else?

comment:4 Changed 7 years ago by dustin

How about MultiCodebaseScheduler?

comment:5 Changed 6 years ago by dustin

  • Milestone changed from 0.8.+ to 0.9.+

Ticket retargeted after milestone closed

comment:6 Changed 6 years ago by dustin

This largely got finished in and (for Nightly)

It could probably be more widely implmented, so the bug can remain open.

Note: See TracTickets for help on using tickets.