| Summary: | buildhistory: version number checking fails when dealing with sha values | ||
|---|---|---|---|
| Product: | [Infrastructure] AutoBuilder | Reporter: | Reinette Chatre <reinette.chatre> |
| Component: | autobuilder | Assignee: | Beth Flanagan <elizabeth.flanagan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | Undecided | CC: | bluelightning, elizabeth.flanagan, infras.ab.watcher, Infras.watcher |
| Version: | 1.2 | ||
| Target Milestone: | --- | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Reinette Chatre
2012-06-29 19:05:32 UTC
Is the persistent db within the cache (TMPDIR/cache/bb_persist_data.sqlite3) being preserved between builds? That's the way this is normally supposed to work - the system recognises a previous hash was built and should increase the number at the start of SRCPV, i.e. in this example it should have gone from 0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git2+1e36f9. If you aren't touching TMPDIR or the cache between builds and it's behaving like this then we have a problem. (In reply to comment #1) > Is the persistent db within the cache (TMPDIR/cache/bb_persist_data.sqlite3) > being preserved between builds? That's the way this is normally supposed to > work - the system recognises a previous hash was built and should increase > the number at the start of SRCPV, i.e. in this example it should have gone > from 0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git2+1e36f9. > > If you aren't touching TMPDIR or the cache between builds and it's behaving > like this then we have a problem. Finally I learn more about that LOCALCOUNT ... previously I played around with BB_LOCALCOUNT_OVERRIDE and a custom LOCALCOUNT and also ran into buildhistory issues. Not related to this though. To answer your questions, yes, indeed ... since this is our official builds I precede them with a complete cleanup ("rm -rf tmp sstate-cache downloads") in an attempt to ensure there are no surprises. If I understood correctly a cleanup of TMPDIR precedes the yocto autobuilder builds also. (In reply to comment #2) > (In reply to comment #1) > > Is the persistent db within the cache (TMPDIR/cache/bb_persist_data.sqlite3) > > being preserved between builds? That's the way this is normally supposed to > > work - the system recognises a previous hash was built and should increase > > the number at the start of SRCPV, i.e. in this example it should have gone > > from 0:3.2.0-v0.3-rc1.1+git1+1776ff to 0:3.2.0-v0.3-rc1.1+git2+1e36f9. > > > > If you aren't touching TMPDIR or the cache between builds and it's behaving > > like this then we have a problem. > > Finally I learn more about that LOCALCOUNT ... previously I played around > with BB_LOCALCOUNT_OVERRIDE and a custom LOCALCOUNT and also ran into > buildhistory issues. Not related to this though. > > To answer your questions, yes, indeed ... since this is our official builds > I precede them with a complete cleanup ("rm -rf tmp sstate-cache downloads") > in an attempt to ensure there are no surprises. If I understood correctly a > cleanup of TMPDIR precedes the yocto autobuilder builds also. Yes, it does, however, and this bit of functionality got left out of the recent upgrade (It's back in now, pending ab restart), the autobuilder takes the old bb_persist_data.sqlite3 and repopulates build/tmp/cache. (In reply to comment #4) > See: > http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder/commit/ > ?id=0c6a76783d255ca6904963c2bd2b72f9dc21fceb Thank you very much for clearing this up. I will work with you to reproduce this solution in our builds. I proceed to mark this bug as resolved. |