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.

Sign up for GitHub

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

Jump to bottom

Get rid of publish-travis.sh #2570

Closed
kailuowang opened this issue Oct 19, 2018 · 4 comments · Fixed by #2737
Closed

Get rid of publish-travis.sh #2570

kailuowang opened this issue Oct 19, 2018 · 4 comments · Fixed by #2737
Labels
build help wanted

Comments

@kailuowang
Copy link
Contributor

The bash script is getting unmanageable.
Instead we can define travis jobs explicitly in a clearer jobs spec, here is a simplified example.

scala: 
    - 2.11.12
    - 2.12.6
    - 2.13.0-M4
jobs:
  include:
    - env:
        - NAME="Validate JVM"
      script:
        - sbt ++$TRAVIS_SCALA_VERSION validateJVM

    - if: env(TRAVIS_SCALA_VERSION) =~ /^2.12/ 
      env:
        - NAME="Validate docs"
      script:
        - sbt docs/tut

    - if: (branch = master) AND (type = pull_request)
      env:
        - NAME="Publish SNAPSHOT"
      script:
        - sbt ++$TRAVIS_SCALA_VERSION publish gitSnapshots publish
@djspiewak
Copy link
Member

FWIW, there is no filesystem caching between job stages, and even if you emulate it by hand (e.g. by using S3 to pass files between stages), you still run into the fact that Zinc is irrationally picky about file state and will often refuse to incrementally compile.

@ceedubs
Copy link
Contributor

ceedubs commented Oct 21, 2018

In case it saves anyone else some time, I went down a bit of a rabbit hole trying to use Travis CI's new "stages" feature, and ran into trouble. I don't entirely understand it, but it seems that the "stages" are part of the build matrix, as is the scala version, and there's some sort of interaction where it tries to create a default stage that just runs test no matter what you do. Or at least that was my experience. Someone who knows more about Travis may be able to do better.

@kailuowang kailuowang mentioned this issue Jan 17, 2019
Closed
@ceedubs
Copy link
Contributor

ceedubs commented Feb 17, 2019

I'm working on this. I'll submit a PR after #2732 is merged.

@ceedubs
Copy link
Contributor

ceedubs commented Feb 17, 2019 •
edited
Loading

On that note: does anyone know why our publish command is publish gitSnapshots publish? Why does publish show up twice?

Edit: I'm guessing it's probably so that we always publish an x.y-SNAPSHOT with the latest changes and separately a x.y-<commit-hash>-SNAPSHOT.

ceedubs added a commit to ceedubs/cats that referenced this issue Feb 18, 2019
@ceedubs
Experiment with modularizing Travis jobs
5412969 
Resolves typelevel#2570

This sets up the Cats Travis build to use Travis's stages feature and
modularizes the Travis jobs. This probably introduces a little bit of
extra overhead since each new job needs to spin up a virtual machine and
pull the cache. However, I think that this extra overhead is offset by a
number of factors (see further below).

We are now only publishing code coverage reports for the default Scala
version (currently 2.12.x). I don't think that publishing multiple
coverage reports for the same commit even has well-defined results, and
I suspect that we didn't really mean to do that. Since running the tests
with code coverage is probably the most time-consuming thing that the
tests do, this is a significant time saver.

Each individual job has a smaller run duration (usually < 20 min). This
means that if an individual job does fail and we have to restart it, we
are waiting for a smaller amount of time than previously.

In theory at least, there's more ability for parallelization. In testing
on my fork, it looks like Travis tends to run 3 to 5 jobs in parallel.
So since we already had that many jobs before, this may not be much of a
win.

Modularizing the build allowed for a few small installation
optimizations (only installing jekyll for the docs job, only installing
node.js for the JS builds, etc).

Lastly, I'm hoping that this sets the stage to move toward releasing via
[sbt-ci-release](https://github.com/olafurpg/sbt-ci-release) instead of
requiring a maintainer to awkwardly publish from their personal
computer. This new Travis configuration allows us to run a bunch of
tests/validation in parallel and then if all goes well, move on to a
stage that is responsible for releasing. Since each job has its own time
limit, we can probably avoid previous problems of releasing from Travis
causing builds to take too long.

Note that Travis stages have awkward interactions with the build matrix,
so I'm now using YAML anchors (essentially templates) to reduce
duplication rather than the build matrix. This allows for finer-grained
control that I think works out pretty nicely.
ceedubs added a commit to ceedubs/cats that referenced this issue Feb 18, 2019
@ceedubs
Experiment with modularizing Travis jobs
84df556 
Resolves typelevel#2570

This sets up the Cats Travis build to use Travis's stages feature and
modularizes the Travis jobs. This probably introduces a little bit of
extra overhead since each new job needs to spin up a virtual machine and
pull the cache. However, I think that this extra overhead is offset by a
number of factors (see further below).

We are now only publishing code coverage reports for the default Scala
version (currently 2.12.x). I don't think that publishing multiple
coverage reports for the same commit even has well-defined results, and
I suspect that we didn't really mean to do that. Since running the tests
with code coverage is probably the most time-consuming thing that the
tests do, this is a significant time saver.

Each individual job has a smaller run duration (usually < 20 min). This
means that if an individual job does fail and we have to restart it, we
are waiting for a smaller amount of time than previously.

In theory at least, there's more ability for parallelization. In testing
on my fork, it looks like Travis tends to run 3 to 5 jobs in parallel.
So since we already had that many jobs before, this may not be much of a
win.

Modularizing the build allowed for a few small installation
optimizations (only installing jekyll for the docs job, only installing
node.js for the JS builds, etc).

Lastly, I'm hoping that this sets the stage to move toward releasing via
[sbt-ci-release](https://github.com/olafurpg/sbt-ci-release) instead of
requiring a maintainer to awkwardly publish from their personal
computer. This new Travis configuration allows us to run a bunch of
tests/validation in parallel and then if all goes well, move on to a
stage that is responsible for releasing. Since each job has its own time
limit, we can probably avoid previous problems of releasing from Travis
causing builds to take too long.

Note that Travis stages have awkward interactions with the build matrix,
so I'm now using YAML anchors (essentially templates) to reduce
duplication rather than the build matrix. This allows for finer-grained
control that I think works out pretty nicely.
ceedubs added a commit to ceedubs/cats that referenced this issue Feb 18, 2019
@ceedubs
Experiment with modularizing Travis jobs
4afe71b 
Resolves typelevel#2570

This sets up the Cats Travis build to use Travis's stages feature and
modularizes the Travis jobs. This probably introduces a little bit of
extra overhead since each new job needs to spin up a virtual machine and
pull the cache. However, I think that this extra overhead is offset by a
number of factors (see further below).

We are now only publishing code coverage reports for the default Scala
version (currently 2.12.x). I don't think that publishing multiple
coverage reports for the same commit even has well-defined results, and
I suspect that we didn't really mean to do that. Since running the tests
with code coverage is probably the most time-consuming thing that the
tests do, this is a significant time saver.

Each individual job has a smaller run duration (usually < 20 min). This
means that if an individual job does fail and we have to restart it, we
are waiting for a smaller amount of time than previously.

In theory at least, there's more ability for parallelization. In testing
on my fork, it looks like Travis tends to run 3 to 5 jobs in parallel.
So since we already had that many jobs before, this may not be much of a
win.

Modularizing the build allowed for a few small installation
optimizations (only installing jekyll for the docs job, only installing
node.js for the JS builds, etc).

Lastly, I'm hoping that this sets the stage to move toward releasing via
[sbt-ci-release](https://github.com/olafurpg/sbt-ci-release) instead of
requiring a maintainer to awkwardly publish from their personal
computer. This new Travis configuration allows us to run a bunch of
tests/validation in parallel and then if all goes well, move on to a
stage that is responsible for releasing. Since each job has its own time
limit, we can probably avoid previous problems of releasing from Travis
causing builds to take too long.

Note that Travis stages have awkward interactions with the build matrix,
so I'm now using YAML anchors (essentially templates) to reduce
duplication rather than the build matrix. This allows for finer-grained
control that I think works out pretty nicely.
@ceedubs ceedubs mentioned this issue Feb 18, 2019
Merged
kailuowang pushed a commit that referenced this issue Feb 27, 2019
@ceedubs @kailuowang
Experiment with modularizing Travis jobs (#2737)
ab0e5bf 
Resolves #2570

This sets up the Cats Travis build to use Travis's stages feature and
modularizes the Travis jobs. This probably introduces a little bit of
extra overhead since each new job needs to spin up a virtual machine and
pull the cache. However, I think that this extra overhead is offset by a
number of factors (see further below).

We are now only publishing code coverage reports for the default Scala
version (currently 2.12.x). I don't think that publishing multiple
coverage reports for the same commit even has well-defined results, and
I suspect that we didn't really mean to do that. Since running the tests
with code coverage is probably the most time-consuming thing that the
tests do, this is a significant time saver.

Each individual job has a smaller run duration (usually < 20 min). This
means that if an individual job does fail and we have to restart it, we
are waiting for a smaller amount of time than previously.

In theory at least, there's more ability for parallelization. In testing
on my fork, it looks like Travis tends to run 3 to 5 jobs in parallel.
So since we already had that many jobs before, this may not be much of a
win.

Modularizing the build allowed for a few small installation
optimizations (only installing jekyll for the docs job, only installing
node.js for the JS builds, etc).

Lastly, I'm hoping that this sets the stage to move toward releasing via
[sbt-ci-release](https://github.com/olafurpg/sbt-ci-release) instead of
requiring a maintainer to awkwardly publish from their personal
computer. This new Travis configuration allows us to run a bunch of
tests/validation in parallel and then if all goes well, move on to a
stage that is responsible for releasing. Since each job has its own time
limit, we can probably avoid previous problems of releasing from Travis
causing builds to take too long.

Note that Travis stages have awkward interactions with the build matrix,
so I'm now using YAML anchors (essentially templates) to reduce
duplication rather than the build matrix. This allows for finer-grained
control that I think works out pretty nicely.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
build help wanted
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Experiment with modularizing Travis jobs ceedubs/cats
3 participants
@djspiewak @kailuowang @ceedubs