Are Travis Workspaces immutable?

Hi,

I’m not sure whether the following “problem” is by design or rather a bug, but either way it is undocumented or at least was not clear for me.

TLDR;
It looks like that after the first creation of a workspace, there is no way to update it, either

  • if I (manually) rerun the first and only job which has created and used it the same time
  • if there are multiple jobs with create/use statements for the same(!!!) workspace name.

Since in the logs for workspaces we can see some trace of intention of change detection, I would have expected it to always update itself after the first creation if there was any change:

Creating workspaces
Workspace: <workspace name>
adding <path> to workspace
changes detected, packing new archive

A more detailed example
We have some e2e tests which sometimes fail for unrelated reasons to the current code change (BE is down, slow, busy, etc). For this we have a mechanism in place to store what has passed previously and what not (within one job). When (manually re)running a job (even multiple times), we always update the record of test status and only run those which have been failed previously. Like this, in an incremental way we wanted to squeeze through jobs which are fragile. (let’s not talk about whether it is a good solution or not, this is not the point)

Let’s say we have a job, which has 10 e2e tests:

  1. for the first run 5 pass, 5 fail (we store each test’s status)
  2. for the second (manually triggered) rerun we have 5 tests to run (the previously failed ones), now 3 pass, 2 fail (we store each test’s status again)
  3. for the third (manually triggered) rerun we have 2 tests to run (the previously failed ones), now 2 pass and we are done (we store each test’s status again)

The problem is that it seems storing this information in Travis Workspaces is a no go, because as we found after the first time of the workspace had been created, it always says:

Creating workspaces
Workspace: <workspace name>
adding <path> to workspace
nothing changed

despite the fact that it was changed, we even debugged/echoed the changed files, so it seems that it doesn’t update the workspace for consecutive reruns, even if changes were really made.

Also it is worth to mention that this “unable to update ‘workspaced’ folder” can’t be reproduced in debug mode.

Thanks,
Andras

According to casher/casher at 2e5f0cbfd79ea4b50daed507ef87813df9a28f5e · travis-ci/casher · GitHub, it calculates and compares MD5 checksums with md5deep to detect changes. So if you really updated files in the directories, it should see it.

I suggest to check the contents of directories in the workspace and also in which sequence it’s being restored and saved.
It may be that either you save changed files somewhere else, or there’s a race condition in the saving/restoring sequence.

Also keep in mind that workspaces aren’t preserved across builds – you need to use caches for that.