Introducing Workspaces

Early Releases
1

We are working on workspaces, a new way of sharing files within a build.

Workspaces allow jobs within a build to share files. They are useful when you want to use build artifacts from a previous job; for example, you create a cache that can be used in multiple jobs later.

Example configurations and further information can be found in https://docs.travis-ci.com/user/using-workspaces/.

We very much appreciate your feedback here.

Thank you!

7 Likes
3

create_workspace logic should probably run after before_cache: script.

In https://api.travis-ci.org/v3/job/560286391/log.txt (build link), I use a stage to build a shared dependency, then add the result to both cache and workspace. Before saving the cache, I clean up the directories from redundant data in before_cache:. As it is now, the workspace is saved with that redundant data.

1 Like
4

Thatā€™s a fair point.

5

6 posts were split to a new topic: Allow to restore a workspace in another OS

10

We just switched to using workspaces in snapcraft. Working well for our use case,

11

@BanzaiMan, Iā€™d like to confirm with you that my understanding of how workspace works is correct.

Letā€™s say I have a simple 3-stage pipeline:

jobs:
  include:
    - stage: Build
      script: # compiles sources
      workspaces:
        create:
          name: shared
          paths: .

    - stage: Test
      workspaces:
        use: shared
      script: # compiles tests, runs them and generates coverage reports

    - stage: Scan
      workspaces:
        use: shared
      script: # does analysis and collects other metrics

Am I right that both Test and Scan stages will use the shared workspace in read-only mode? In other words, Scan will not see any changes made by the Test stage, correct?

Thank you!

12

Thatā€™s correct. If there is no reason for the Scan stage to wait for the Test stage to finish, you will save yourself some wall clock time by running them in the same stage.

13

@BanzaiMan, thank you for the confirmation.

The reason Iā€™m having them separately is to provide better control over execution time. Also depending on the case, Iā€™d like to run them in different groups: only (1) or (2), (1) and (2), all of them. Let me know if you see any problems with this.

I raised the question because after migrating from Travis shared caches to workspaces I accidentally broke the analytics on the Scan stage :slight_smile: I guess the reason is clear know. Is it possible to update the workspace with the changes made on stage Test?

So far I tried the trick with two workspaces:

jobs:
  include:
    - stage: Build
      script: # compiles sources
      workspaces:
        create:
          name: compiled_sources
          paths: .

    - stage: Test
      script: # compiles tests, runs them and generates coverage reports
      workspaces:
        create:
          name: test_results
          paths: .
        use: compiled_sources

    - stage: Scan
      workspaces:
        use: test_results
      script: # does analysis and collects other metrics

And looks like it should be working, but now for each stage, I have two jobs:
(1) a new one which uses either compiled_sources or test_results workspaces
(2) the old one which uses the outdated shared workspace

Is that expected? How can I drop the shared workspace?
Note: I triggered the pipeline manually using the ā€œTrigger a custom build (Beta)ā€ feature, could it be the reason?

Thanks!

14

Do workspaces still work? The documentation page labels them beta, and in my builds Iā€™m getting validation errors on my .travis.yml when I use them.

2 Likes
15

@retorquere Yes, they work, and no, they are not in the validatorā€™s schema for some reason. Thereā€™s a half-year old open PR by @svenfuchs to add them there.

16

Workspaces have been out for several months now without any changes to the interface. Looks like itā€™s pretty safe to bring them out of beta.