Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • buildstream buildstream
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 297
    • Issues 297
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 21
    • Merge requests 21
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • BuildStreamBuildStream
  • buildstreambuildstream
  • Issues
  • #215
Closed
Open
Issue created Jan 26, 2018 by Chandan Singh@cs-shadowMaintainer

Workspace builds might not rebuild correctly when dependecies are updated

After !126 (merged) was landed, we realized that incremental workspace builds might not do the right thing in certain scenarios. Consider the following scenario:

  • Element B depends on Element A
  • User opens a workspace for B
  • User builds B, so its workspace now has all the .o files and the underlying build system (make for instance) will not rebuild it on subsequent builds
  • Now, the dependency A is updated so BuildStream will rebuild A and schedule B for rebuild too the next time one tries to build B
  • Since A doesn't has a workspace associated with it, all the updated files in A will have a timestamp from 1970 within the sanbbox
  • BuildStream will try to rebuild B but since it already has all the .o files will have a much newer timestamp than the header files form A, build systems like make won't do a rebuild

So to summarize, if the dependencies of a workspaced element are updated, they might not get rebuilt properly since the timestamps of all non-workspaced files will be ancient.


If someone comes across this issue, the immediate short-term solution would be to reset the workspace when your dependencies are updated. But we will probably need a better solution for the medium to long term. Perhaps we need a manifest of some sort but I'm not sure at present.

Edited Jan 26, 2018 by Chandan Singh
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking