CI?

[zbeekman]

I’ve just started learning how to use Travis CI, and setting something up for this project wouldn’t be too bad. Once #27 and #30 are resolved we could add the tests to the CI system… I hope to get to them soon, btw, sorry for the delay. We could then add a fancy travis-ci build status badge to the homepage. The build could only be tested with gfortran, AFAICT, but it could be tested on Linux and Mac, and using all of the build systems.

[jacobwilliams]

I'm all for it!

[szaghi]

I have just used travis for some Fortran codes, it is very helpful to find
new bugs introduced into too fast commits :-). Having joson-fortran testing
on travis it is a valuable plus. See you soon

Il giorno 02:29 sab 14/feb/2015 Jacob Williams notifications@github.com
ha scritto:

I'm all for it!

—
Reply to this email directly or view it on GitHub
#42 (comment)
.

[jacobwilliams]

I fiddled with it a bit as an experiment. It doesn't work yet...will look at it again later.

[jacobwilliams]

I got something crude working now (with the current example program), mainly by trial and error. We can expand/improve on it as we go.

[zbeekman]

Ok, I was going to work up a pull request to implement this today, but I guess you beat me to it. I may still hack at it a bit. Obviously testing with the Intel compilers is likely precluded unless we can figure out how to install one of our copies on the travis VM. However, now that gfortran 49 compiles this, we can just stick to testing with that.

I'd like to test all 3 build systems (maybe in parallel) and also run the tests. I'll try to get to #27 and #30 too.

[zbeekman]

Here’s an idea, that may or may not appeal to you, @jacobwilliams, let me know:

• Let travis build the ROBODoc documentation and push it (deploy it) to the proper place on the gh-pages branch automatically.
  • Once this is setup correctly, you’ll never have to deploy the documentation again (or forget to do so)
  • It will keep the documentation up to date automagically for:
    • the master branch
    • all future releases/tags

I found a blog post describing how someone does this with their CV on their website: http://johntfoster.github.io/posts/managing-a-professional-website.html I could build this functionality into the PR I am working up…

[jacobwilliams]

Now that is quite interesting...

Currently, I keep the documentation for the different releases in different directories here. The ideal solution would be for it to automatically update this file when there is a new release, add the appropriate link with the release name (4.0.0, etc.), and create the directory and add the files. Also, I could add a dev directory where it puts the doc files for the current state of the master branch.

[zbeekman]

+1 for the dev or master directory so that we can keep an eye on the docs as we hack…

I need to snoop around about releases etc. but I think it should be possible to auto-deploy the robodoc documentation.

[szaghi]

Hi Izaak,

thank you very much for the link to the Foster blog post, it is very interesting.

I used Tavis only for checking stuffs and, until now, I do not understand how it can be helpful for automatically deploying after_success outputs... very very interesting.

See you soon.

[zbeekman]

I think line 27 of .travis.yml could cause the build to fail since, I think, travis can execute stuff on different lines asynchronously. I would have something like:

script:
    - cd bin && ./json

[zbeekman]

@jacobwilliams I’m working on implementing the CI documentation auto deployment, but had a few questions for you:

1. I’m looking at a diff of the documentation generated just by running build.sh for tag 3.0.0 and the contents of the gh-pages branch’s 3.0.0 folder, can you help explain the following differences:
   1. json_module__test_f90.html is only in the 3.0.0 folder. What is the purpose of this file and how was it generated? Is it included on purpose or by accident? It looks, perhaps like it is old/stale and should be removed, because I don’t think it’s reachable using any other links.
   2. robo_methods.html is only in the 3.0.0 folder. What is the purpose of this file and how was it generated? Is it included on purpose or by accident? It looks, perhaps like it is old/stale and should be removed, because I don’t think it’s reachable using any other links.
   3. From the diff, it would appear that the only other change that happened was: <a name=“robo_top_of_doc”>jsonfortran</a> was changed to <a name=“robo_top_of_doc”>jsonfortran_3.0.0</a> in every file… this should be easy to do programmatically.
2. Is it OK if I call the development version’s folder master and link to it as: “Current Development Master Branch” underneath the “Releases” link?
3. Is it OK if I rename the “Versions” header to “Official Release Versions”?

I’m going to setup auto-deploy on my fork and do some testing, hopefully I’ll get a PR to you soon, if you answer these questions, and things look good to you.

[jacobwilliams]

i and ii. Yes, these shouldn't have been committed. I'll delete them.
iii. Not sure...will look at it when I'm at my computer.
2&3. Yes, that's fine.
Thanks!

[zbeekman]

I deleted the erroneous files in the PR #57. Haven’t implemented auto deploy yet, but changes in #57 need to happen first

[szaghi]

Hi Izaak and Jacob,

following your suggestions I have successfully setting-up travis-ci for auto-deploying Lib_VTK_IO API documentation, see this into the after_success section.

Thank you very much for sharing your knowledge.

See you soon.

[zbeekman]

@szaghi I've also already implemented this, in PR #59. @jacobwilliams is just a bit busy at the moment and hasn't had a chance to review it yet.

[szaghi]

Hi Izaak,
yes I followed your suggestions. In my case I have not the necessity to write a stand-alone deploy script, my API doc deployment is very simple (purge the old and push the new just created) and can be easily done directly into the travis.yaml. Anyhow, it is very interesting to read you deploy script, it will be useful for a more complex scenario such as json-fortran.

Thank you again.

See you soon.

[zbeekman]

Close, or wait for coverage?

[jacobwilliams]

Close. It's working great! Track coverage at Issue #63.