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.

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

Merged
merged 7 commits into from
Nov 10, 2018
Merged

Build GMT docs #175

merged 7 commits into from
Nov 10, 2018

Conversation

seisman
Copy link
Member

@seisman seisman commented Nov 9, 2018

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.

@seisman seisman changed the title WIP: Build GMT docs Build GMT docs Nov 9, 2018
@seisman seisman requested a review from leouieda November 9, 2018 16:02
@joa-quim
Copy link
Member

joa-quim commented Nov 9, 2018

Does this mean that the docs are going to be (re)build for every commit?

@seisman
Copy link
Member Author

seisman commented Nov 9, 2018

@joa-quim Yes.

@joa-quim
Copy link
Member

joa-quim commented Nov 9, 2018

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.

@seisman
Copy link
Member Author

seisman commented Nov 9, 2018

As mentioned in #53, it's possible to use some magic strings like +DOCS to dynamically trigger the documentations build.

@PaulWessel
Copy link
Member

@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.

@PaulWessel
Copy link
Member

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.

@joa-quim
Copy link
Member

joa-quim commented Nov 9, 2018

Yes, clean builds also build the PDF and, at least on Win, I think is ex19 alone takes minutes to create.
I really think we should not build the docs when there were no changes whatsoever on them.

@joa-quim
Copy link
Member

joa-quim commented Nov 9, 2018

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.

Bur aren't the tests exactly for that? And that small change wouldn't go unnoticed?

@seisman
Copy link
Member Author

seisman commented Nov 9, 2018

@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.

@seisman
Copy link
Member Author

seisman commented Nov 9, 2018

The travis docs say that:

To check whether a build was triggered by cron, 
examine the TRAVIS_EVENT_TYPE environment variable to see if it has the value cron.

@PaulWessel
Copy link
Member

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?

@leouieda
Copy link
Member

Bur aren't the tests exactly for that?

You're right. Building the docs always is probably not a great solution.

@seisman adding an if that checks for TRAVIS_EVENT_TYPE would be enough to make it trigger only in cron jobs. I think Travis can probably handle a nightly build.

Copy link
Member

@leouieda leouieda left a 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"
Copy link
Member

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
Copy link
Member

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;
Copy link
Member

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?

Copy link
Member

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- if [ "$BUILD_DOCS" == "true" ]; then
- if [ "$TRAVIS_EVENT_TYPE" == "cron" ]; then

@seisman
Copy link
Member Author

seisman commented Nov 10, 2018

@leouieda I've made changes as requested. Please review it again.

@leouieda
Copy link
Member

@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?

@leouieda
Copy link
Member

This is good to merge if @seisman has nothing more to add.

@seisman seisman merged commit 75d6b57 into master Nov 10, 2018
@seisman seisman deleted the build-docs branch November 10, 2018 03:10
@seisman
Copy link
Member Author

seisman commented Nov 10, 2018

Should we set this to run nightly?

@leouieda I've set a nightly build. Feel free to set it weekly or monthly.

@leouieda
Copy link
Member

Perfect!

obaney pushed a commit to obaney/gmt that referenced this pull request Aug 18, 2021
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants