Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-10588

Create texlive docker image for lsst-texmf projects

    XMLWordPrintable

    Details

      Description

      It can take a while to build a lsst-texmf document on Travis CI. The trouble is that we're installing a full texlive every time. It might be more efficient to download a Docker image with texlive pre-installed and run the latex build from that container.

      One question is whether to include lsst-texmf or not with the image. I think it may be wise to create a base image without lsst-texmf since some projects will include lsst-texmf as a submodule. Then a second Docker image, with a Dockerfile in the lsst-texmf project, can layer lsst-texmf upon that.

        Attachments

          Issue Links

            Activity

            Hide
            rhl Robert Lupton added a comment -

            So this is purely for the sake of travis? Presumably other people could use it, but we'll expect project people to have TeX installed, and then pull lsst-texmf.

            Show
            rhl Robert Lupton added a comment - So this is purely for the sake of travis? Presumably other people could use it, but we'll expect project people to have TeX installed, and then pull lsst-texmf.
            Hide
            tjenness Tim Jenness added a comment -

            Yes. Although we won't stop people using it i they want. Most people have texlive installed somewhere already. The thorny issue is how people get access to lsst-texmf. One camp says they should clone it and set TEXMFHOME or TEXMFLOCAL as appropriate. The other camp says we should have an lsst-texmf submodule in each document repository so as to ensure that people have access to it (the Makefile will know where it is) and that the version used to build the document is known to work (rather than being a random version that could in theory break the document build). The "provide your own copy somewhere" camp are currently in ascendance.

            Show
            tjenness Tim Jenness added a comment - Yes. Although we won't stop people using it i they want. Most people have texlive installed somewhere already. The thorny issue is how people get access to lsst-texmf. One camp says they should clone it and set TEXMFHOME or TEXMFLOCAL as appropriate. The other camp says we should have an lsst-texmf submodule in each document repository so as to ensure that people have access to it (the Makefile will know where it is) and that the version used to build the document is known to work (rather than being a random version that could in theory break the document build). The "provide your own copy somewhere" camp are currently in ascendance.
            Hide
            tjenness Tim Jenness added a comment -

            Regarding lsst-texmf in docker. Yes, texlive changes much more slowly than lsst-texmf. This is mainly because lsst-texmf includes the shared bibliography files and newer versions of documents may need up to date bib entries.

            Show
            tjenness Tim Jenness added a comment - Regarding lsst-texmf in docker. Yes, texlive changes much more slowly than lsst-texmf. This is mainly because lsst-texmf includes the shared bibliography files and newer versions of documents may need up to date bib entries.
            Hide
            rhl Robert Lupton added a comment -

            set TEXMFHOME or TEXMFLOCAL as appropriate

            or TEXINPUTS? But why is one choice not always right, so it could be set in a table file

            Show
            rhl Robert Lupton added a comment - set TEXMFHOME or TEXMFLOCAL as appropriate or TEXINPUTS ? But why is one choice not always right, so it could be set in a table file
            Hide
            tjenness Tim Jenness added a comment -

            Jim Bosch already sets TEXMFLOCAL in a table file in lsst-texmf (see https://github.com/lsst/lsst-texmf/pull/43). We aren't mandating eups for latex documents though and it doesn't solve the problem with ensuring the document is built with exactly the right version of lsst-texmf.

            I don't believe TEXINPUTS is the correct variable to use. TEXMFLOCAL is what you should use for a shared distribution and TEXMFHOME is what you should use for user-local packages.

            Show
            tjenness Tim Jenness added a comment - Jim Bosch already sets TEXMFLOCAL in a table file in lsst-texmf (see https://github.com/lsst/lsst-texmf/pull/43 ). We aren't mandating eups for latex documents though and it doesn't solve the problem with ensuring the document is built with exactly the right version of lsst-texmf. I don't believe TEXINPUTS is the correct variable to use. TEXMFLOCAL is what you should use for a shared distribution and TEXMFHOME is what you should use for user-local packages.
            Hide
            jsick Jonathan Sick added a comment -

            I've recorded Travis CI build times decreasing from 8 minutes to 3.5 minutes. Theoretically, the build times can be reduced to less than a minute if we eventually move to Jenkins CI where we can cache images.

            Show
            jsick Jonathan Sick added a comment - I've recorded Travis CI build times decreasing from 8 minutes to 3.5 minutes. Theoretically, the build times can be reduced to less than a minute if we eventually move to Jenkins CI where we can cache images.
            Hide
            jsick Jonathan Sick added a comment -

            Adam Thornton, could you check the sanity of the Dockerfile and also the Travis -> Docker Hub approach I've taken?

            Show
            jsick Jonathan Sick added a comment - Adam Thornton , could you check the sanity of the Dockerfile and also the Travis -> Docker Hub approach I've taken?

              People

              Assignee:
              jsick Jonathan Sick
              Reporter:
              jsick Jonathan Sick
              Reviewers:
              Adam Thornton
              Watchers:
              Adam Thornton, Jonathan Sick, Robert Lupton, Tim Jenness
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.