Skip to content

perfsonar/docs

Folders and files

NameName
Last commit message
Last commit date
May 14, 2024
Jan 15, 2025
Apr 17, 2023
Oct 2, 2024
Apr 4, 2022
Sep 2, 2020
Sep 2, 2020
Jun 24, 2024
Aug 19, 2014
Sep 2, 2020
Apr 2, 2024
May 27, 2022
Jan 15, 2025
Apr 2, 2024
Apr 2, 2024
Feb 11, 2016
Feb 11, 2016
Apr 14, 2017
Jun 24, 2024
Jun 24, 2024
Aug 19, 2014
Nov 2, 2020
Mar 17, 2021
Sep 2, 2020
May 8, 2024
Sep 2, 2020
Sep 2, 2020
Nov 2, 2018
May 24, 2019
Feb 7, 2024
Apr 13, 2023
Apr 9, 2024
Mar 28, 2023
Jun 10, 2024
Jun 24, 2024
Jun 6, 2024
Jan 15, 2025
Jun 14, 2023
Apr 5, 2023
Apr 5, 2023
Aug 22, 2024
Jun 20, 2024
Jun 24, 2024
Jun 12, 2024
Jul 2, 2020
Jan 15, 2025
Apr 3, 2023
Apr 9, 2024
May 24, 2018
Jun 6, 2024
May 24, 2018
May 22, 2018
May 8, 2024
Apr 9, 2024
Jun 10, 2024
Jun 14, 2018
Oct 2, 2024
Jun 14, 2023
Apr 9, 2024
Aug 22, 2018
Apr 2, 2024
Oct 10, 2023
Apr 17, 2023
Jan 15, 2025
Apr 9, 2024
Apr 5, 2023
Apr 2, 2024
Dec 22, 2023
Jul 25, 2024
Apr 19, 2018
Feb 7, 2024
Jun 5, 2024
Jun 11, 2024
Apr 2, 2024
Jun 24, 2024
Apr 2, 2024
Apr 2, 2024
Apr 2, 2024
Oct 2, 2024
Apr 5, 2023
Apr 2, 2024
Sep 5, 2019
Apr 2, 2024
Sep 5, 2019
Apr 9, 2024
Oct 8, 2020
Jul 23, 2019
Apr 9, 2024
Jun 10, 2024
Sep 5, 2019
Apr 2, 2024
Feb 13, 2019
Apr 2, 2024
Jul 23, 2019
Jul 23, 2019
Feb 13, 2019
Sep 5, 2019
Apr 2, 2024
Jun 14, 2018
Jun 14, 2018
Jun 14, 2018
Oct 2, 2024
Apr 5, 2024
Jun 15, 2018

Repository files navigation

perfSONAR Documentation

This repository contains installation and configuration documentation related to the perfSONAR project. The master branch contains the raw files for the documents hosted at http://docs.perfsonar.net. See the remainder of the README for more information on editing and deploying the perfSONAR documentation.

Documentation Format

The perfSONAR documentation is generated by Sphinx and uses the reStructuredText format. See those sites for details.

Preparing Your Environment

You will need to build the files using the Sphinx Python Library. You can do this directly on your system or use the proviided docker container.

You can start the container as follows:

cp env.example .env 
docker-compose up -d

Fill-in any git credentials in .env if you plan to use deploy scripts. Any of the commands in the remainder of this document can be executed with docker-compose exec docs_build COMMAND and will run inside container.

Alternatively, for direct install on most systems this means running the following:

pip install sphinx

See http://sphinx-doc.org/install.html for operating system specific instructions.

Previewing the site

From the top-level directory of this repository run:

make html

This will generate a set of HTML files that can be opened in your browser under _build/html/. You can view the main page by opening _build/html/index.html in your browser.

Deploying Documentation to docs.perfsonar.net

Simply push your changes to the master branch and the documentation will be published within 15 minutes to http://docs.perfsonar.net. This is handled by a script running on the hosting server that polls the git repository every 15 minutes and rebuilds the site if changes are detected. If you can't wait that long, run make html followed by deploy.sh to deploy your changes.

Deploying a release candidate

A script is provided to deploy documentation for a release candidate. The basic process is that the documentation for the release candidate is done in a branch and then we push out the branch using a shell script.

Once your branch is ready simply run the deploy_release_candidate.sh script to publish the branch (substituting BRANCH with the BRANCH name):

./deploy_release_candidate.sh BRANCH

This will create a new directory with the docs at http://docs.perfsonar.net/release_candidates/BRANCH. If you need to update existing docs, simply run the script again to push out changes.

Deploying a previous release

A script is provided to deploy documentation for previous releases. The basic process is that the documentation for the previous release must be tagged on master where the version number is the tag. This will in turn create a link under /previous_releases/VERSION with the old version of the documentation.

Following the process above, the first step is to create the tag, where TAG is the version number (e.g. 3.4.2) and COMMIT is the commit hash (e.g. 4305a6e72c0df0b929412fea19f7402f74b1ab8f):

git tag TAG COMMIT

Next we simply run the deploy_prev_release.sh script to publish the tag (again substituting TAG with the version number):

./deploy_prev_release.sh TAG

Finally, you will want to add a link to previous_releases.rst and publish by hand when you are ready to share.