apache / apache/buildstream

Modification time of an element with an open workspace propagates into consumer element's sandbox

Open
#2,186 2 comments 2 reactions 0 assignees View on GitHub
bug
Dominant language
Python
Stars
140
Forks
45
Avg merge
1d 3h
Merged PRs (30d)
6

Description

When an element has a dependency with an open workspace, that dependency's artifacts get staged with their real mtimes instead of the magic timestamp. This can cause differences between builds with and without the workspace.

# Steps to reproduce

A small project to reproduce the issue:

```
.
├── a.txt
├── elements
│ ├── a.bst
│ ├── alpine.bst
│ └── b.bst
└── project.conf
```

The context of `a.txt` are irrelevant, it can be left empty. `elements/a.bst` carries `a.txt`:

```
kind: import

sources:
- kind: local
path: a.txt

config:
target: /
```

`elements/b.bst` has `a.bst` and `alpine.bst` as build dependencies:

```
kind: manual

build-depends:
- alpine.bst
- a.bst
```

project.conf and alpine.bst are set up to pull alpine image

`alpine.bst`:

```
kind: import
description: |

Alpine Linux base runtime

sources:
- kind: tar

# This is a post doctored, trimmed down system image
# of the Alpine linux distribution.
#
url: alpine:integration-tests-base.v1.x86_64.tar.xz
ref: 3eb559250ba82b64a68d86d0636a6b127aa5f6d25d3601a79f79214dc9703639
```

`project.conf`:

```
# Unique project name
name: bug-repro

# Required BuildStream version
min-version: 2.7

# Subdirectory where elements are stored
element-path: elements

aliases:
alpine: https://bst-integration-test-images.ams3.cdn.digitaloceanspaces.com/
```

When no workspace is open, building `b.bst`, opening its build sandbox, and checking the mtime of `a.txt` shows that all is well, and modification time is normalised:

```
$ bst build b.bst
...
$ bst shell --build b.bst
...
[20440600@b.bst:/buildstream/repro/b.bst]$ stat /a.txt
File: /a.txt
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 31h/49d Inode: 2 Links: 1
Access: (0644/-rw-r--r--) Uid: (1876721912/ UNKNOWN) Gid: (1174200513/ UNKNOWN)
Access: 2011-11-11 11:11:11.000000000
Modify: 2011-11-11 11:11:11.000000000
Change: 2011-11-11 11:11:11.000000000
```

If `a.bst`'s workspace is opened first, the modification time is no longer the magic timestamp but the actual `a.bst`'s build time instead:

```
$ bst workspace open a.bst
...
$ bst build b.bst
...
$ bst shell --build b.bst
...
[e1f40f6c@b.bst:/buildstream/repro/b.bst]$ stat /a.txt
File: /a.txt
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 31h/49d Inode: 3 Links: 1
Access: (0644/-rw-r--r--) Uid: (1876721912/ UNKNOWN) Gid: (1174200513/ UNKNOWN)
Access: 2011-11-11 11:11:11.000000000
Modify: 2026-08-25 11:06:30.000000000
Change: 2011-11-11 11:11:11.000000000
```

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the issue with the supplied project, comparing the build sandbox mtime for a.txt with and without `bst workspace open a.bst`. Trace how workspace artifacts are staged into `b.bst`'s sandbox. Done when the workspace and non-workspace builds both preserve the magic timestamp.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
build-system
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.