Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Benchbuild cache coherence for git tmp folder #429

Open
vulder opened this issue Aug 26, 2021 · 2 comments
Open

Benchbuild cache coherence for git tmp folder #429

vulder opened this issue Aug 26, 2021 · 2 comments
Assignees

Comments

@vulder
Copy link
Collaborator

vulder commented Aug 26, 2021

Currently, benchbuild does not detect when the git folder, cached in tmp, is outdated, i.e., there are new commits upstream.
It would be helpful to add an initial fetch before, e.g., version exploration, so BB could discover a newer version that is present upstream.

I guess this conflicts with BB's current state management and could make problems when one want's to reevaluated the currently cached HEAD revision. So, maybe we could add the 'fetching' as a, via config, enableable feature.

@simbuerg
Copy link
Member

simbuerg commented Aug 31, 2021

We can implement that for git sources by default. If a project states that it follows 'HEAD' you cannot assume to have a fixed source in the cache.

If you want a stable and reproducible experiment run, you have to use a project that uses fixed versions.
An example that follows HEAD would be benchbuild/bzip2. In the past I never touched the cache to avoid
any surprises and updating the project every time I want to test a new version was cumbersome.

This behavior was the default before we implemented support for multiple versions per project. If I'm not missing an edge-case, there should not be a problem with a remote update + fetch.

@vulder
Copy link
Collaborator Author

vulder commented Sep 1, 2021

Update + fetch should be enough that does not change the repo state in the cache but pulls in the information of other commits added to remote HEAD. And yes, if a project specifies HEAD one cannot assume that it will always be the same and having a specific tmp/checkout locally is more 'happens to work'. That was a reason why we introduced paper_configs and case_study files that exactly specify which revisions should be locked at.

If a BB user want's to pin a revision, one option could be to inherit from the project, give it a unique name and pin the version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants