-
Notifications
You must be signed in to change notification settings - Fork 343
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
Build GMT docs #175
Build GMT docs #175
Conversation
Does this mean that the docs are going to be (re)build for every commit? |
@joa-quim Yes. |
So, I'm afraid this is not such a good idea. Building the docs is a quite lengthy process and I do not see why a commit in the code would trigger it when the the two are not related. |
As mentioned in #53, it's possible to use some magic strings like |
@leouieda and I have discussed this. Using this feature depends on how quick it will be to build. As it is now, all illustrations as stored as PS files and there is a conversion to PNG (and maybe PDF) taking place during the docs build. We may find that we should also store the PNGs to avoid this step except when the PS has changed. If it takes too long to build then we may wish to make such changes. |
It is not possible to know for sure that a code change does not have an effect on the docs. if we fit a bug in surface or a plot tool it may cause small changes in the plots. |
Yes, clean builds also build the PDF and, at least on Win, I think is ex19 alone takes minutes to create. |
Bur aren't the tests exactly for that? And that small change wouldn't go unnoticed? |
@PaulWessel @joa-quim Travis supports cron jobs. Currently, the master branch will be built every month. Maybe we can change the cron job settings and build the master branch everyday. If a build is triggered by a cron job, then we build the docs and also tests. Otherwise, we only build the sources, which is much faster. |
The travis docs say that:
|
Perhaps a cron job is an acceptable solution. I have gotten used to running the full tests before I submit a pull requests. On my 24-core Mac the tests take ~3 minutes. Building the entire docs from scratch is a bit faster since there are fewer PS to PNG processes; it takes 2.5 minutes. If my patch breaks something in the tests I can then fix before finalizing the PR. The cron job would instead be helpful to make sure we have a pretty recent version of the full docs available for users to browse. Maybe weekly cron? |
You're right. Building the docs always is probably not a great solution. @seisman adding an |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@seisman thanks for setting this up!
.travis.yml
Outdated
- TRAVIS_EVENT_TYPE=cron | ||
- if [ "$TRAVIS_EVENT_TYPE" == "cron" ]; then | ||
export PYTHON=3.6 | ||
export CONDA_REQUIREMENTS="ci/requirements.txt" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need for a requirements file. You can set CONDA_INSTALL_EXTRA="sphinx"
(see here).
.travis.yml
Outdated
|
||
before_install: | ||
# Install GMT dependencies | ||
- bash ci/travis-setup.sh | ||
- if [ "$BUILD_DOCS" == "true" ]; then | ||
# Install GMT documentation dependencies | ||
# Get the Fatiando CI scripts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Travis doesn't like these comments inside blocks. You have to put them out of the if
or they can't parse the yml file.
.travis.yml
Outdated
|
||
install: | ||
# Build and install GMT | ||
- bash ci/travis-build.sh; | ||
- if [ "$BUILD_DOCS" == "true" ]; then | ||
# Build GMT documentations | ||
bash ci/travis-build-docs.sh; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a script for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The build should probably be part of the script
block as well since this is pretty much part of the tests.
.travis.yml
Outdated
- if [ "$TRAVIS_EVENT_TYPE" == "cron" ]; then | ||
export PYTHON=3.6 | ||
export CONDA_REQUIREMENTS="ci/requirements.txt" | ||
export BUILD_DOCS=true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
export BUILD_DOCS=true |
Probably no need for this variable as well since we're only building on cron jobs.
.travis.yml
Outdated
|
||
before_install: | ||
# Install GMT dependencies | ||
- bash ci/travis-setup.sh | ||
- if [ "$BUILD_DOCS" == "true" ]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- if [ "$BUILD_DOCS" == "true" ]; then | |
- if [ "$TRAVIS_EVENT_TYPE" == "cron" ]; then |
Could probably merge this block with the one further up. The env
block is for setting the build matrix.
.travis.yml
Outdated
|
||
install: | ||
# Build and install GMT | ||
- bash ci/travis-build.sh; | ||
- if [ "$BUILD_DOCS" == "true" ]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- if [ "$BUILD_DOCS" == "true" ]; then | |
- if [ "$TRAVIS_EVENT_TYPE" == "cron" ]; then |
@leouieda I've made changes as requested. Please review it again. |
@seisman looks good to me. The docs seem to build without error and it takes 223s so not too bad. Should we set this to run nightly? |
This is good to merge if @seisman has nothing more to add. |
@leouieda I've set a nightly build. Feel free to set it weekly or monthly. |
Perfect! |
Uses the new LibGMT.info to check if GMT is at least 6.0.0. Raises a GMTVersionError exception if it's not. It would be great if we could check this upon instantiation but that wouldn't work because `LibGMT.get_default` requires an active session. So the only logical place to put this is in `LibGMT.__enter__` after the session is created. The session is closed before the exception is raised. Fixes GenericMappingTools#171
This PR adds GMT documentations builds. Since the sphinx of travis's OS (Ubuntu 14.04) is too old, I install python and sphinx via miniconda.