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

Rust: Because of wrong modified timestamp cargo rebuilds every time #524

Open
geropl opened this issue Apr 26, 2019 · 9 comments
Open

Rust: Because of wrong modified timestamp cargo rebuilds every time #524

geropl opened this issue Apr 26, 2019 · 9 comments
Labels
component: ws-daemon meta: never-stale This issue can never become stale team: workspace Issue belongs to the Workspace team type: bug Something isn't working

Comments

@geropl
Copy link
Member

geropl commented Apr 26, 2019

Describe the bug
Between workspace restarts, the precision of the 'modified' timestamp on files under /workspace degrades from nanosecond to second precision.

As of now, cargo relies on this timestamp to detect dirty dependencies. The effect is that cargo rebuilds the whole project including all dependencies on each restart because it things the present artifacts are outdated.

To Reproduce

  1. Create new workspace
  2. touch test
  3. stat test
  4. Stop and restart workspace
  5. stat test

Expected behavior
Workspace should have identical timestamps after restart.

@geropl geropl added type: bug Something isn't working language: rust labels Apr 26, 2019
@svenefftinge
Copy link
Member

Oh, could that be the reason why cargo-watch is constantly rebuilding a project?
See https://spectrum.chat/gitpod/general/rust-rocket-web-server-port-not-served~cf954a11-8b39-4979-9ebb-5b02949ddf63

@geropl
Copy link
Member Author

geropl commented Apr 29, 2019

No, that sounds like something different. I'll try it, though.

Update: That seems to be indeed a special case, behaves the same locally for me: https://spectrum.chat/gitpod/general/rust-rocket-web-server-port-not-served~cf954a11-8b39-4979-9ebb-5b02949ddf63?m=MTU1NjUyNDEyMzEyNw==

@stale
Copy link

stale bot commented Mar 18, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Mar 18, 2021
@geropl
Copy link
Member Author

geropl commented Mar 19, 2021

Oh, forgot about this one. Will verify and see if I can fix it.

@stale stale bot removed the meta: stale This issue/PR is stale and will be closed soon label Mar 19, 2021
@stale
Copy link

stale bot commented Jun 17, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Jun 17, 2021
@stale stale bot closed this as completed Jun 27, 2021
@geropl geropl added component: ws-daemon meta: never-stale This issue can never become stale team: workspace Issue belongs to the Workspace team and removed language: rust meta: stale This issue/PR is stale and will be closed soon labels May 6, 2022
@geropl
Copy link
Member Author

geropl commented May 6, 2022

Still the case, cmp. mtime here:
image

@axonasif
Copy link
Member

Here's a workaround, use the following task structure in .gitpod.yml:

tasks:
  - name: Build and run
    init: |
      cargo build

      # workaround for https://github.com/gitpod-io/gitpod/issues/524
      find target -exec stat --format='%.Y %n' {} + > /workspace/.ts

    command: |
      # workaround for https://github.com/gitpod-io/gitpod/issues/524
      while read -r ts file; do touch -d "@${ts}" "${file}"; done < /workspace/.ts

      cargo run

@mustard-mh
Copy link
Contributor

Modify time is not changed after workspace restart. As changes is inside component ws-daemon, fixing will land gitpod.io once next gen of workspace cluster deployed.

cc @kylos101 if we have any plan about next gen of workspace cluster

image

@kylos101
Copy link
Contributor

kylos101 commented Jun 7, 2024

👋 @mustard-mh , we probably won't replace workspace clusters for 2-3 more weeks, I think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: ws-daemon meta: never-stale This issue can never become stale team: workspace Issue belongs to the Workspace team type: bug Something isn't working
Projects
No open projects
Status: No status
Development

No branches or pull requests

5 participants