Skip to content

Latest commit

 

History

History
235 lines (187 loc) · 9.98 KB

CONTRIBUTING.md

File metadata and controls

235 lines (187 loc) · 9.98 KB
Raw

Contributing

The Common Workflow Language project is an open source project, and we welcome contributions of all kinds: new sections, fixes to existing material, bug reports, and reviews of proposed changes are all welcome.

Contributor Agreement

By contributing, you agree that we may redistribute your work under our license. In exchange, we will address your issues and/or assess your change proposal as promptly as we can, and help you become a member of our community. Everyone involved in the Common Workflow Language project agrees to abide by our code of conduct.

How to Contribute

The easiest way to get started is to file an issue to tell us about a spelling mistake, some awkward wording, or a factual error. This is a good way to introduce yourself and to meet some of our community members.

  1. If you do not have a GitHub account, you can send us comments by email. However, we will be able to respond more quickly if you use one of the other methods described below.

  2. If you have a GitHub account, or are willing to create one, but do not know how to use Git, you can report problems or suggest improvements by creating an issue. This allows us to assign the item to someone and to respond to it in a threaded discussion.

  3. If you are comfortable with Git, and would like to add or change material, you can submit a pull request (PR). Instructions for doing this are included below.

  4. To build and run the user guide locally, see Building below

Note: The published version of the user guide https://www.commonwl.org/user_guide/ is built from the release branch. New changes are gathered on the default (main) branch which is built at https://common-workflow-languageuser-guide.readthedocs.io/en/latest/ as a preview. Once we collect many changes from the main branch, we merge them into the release branch.

Pull requests include an automatic preview provided by ReadTheDocs.

What to Contribute

There are many ways to contribute, like updating or filling in the documentation and submitting bug reports about things that don't work, aren't clear, or are missing. If you are looking for ideas, please see the list of issues for this repository, or the issues for Common Workflow Language project itself.

Comments on issues and reviews of pull requests are just as welcome: we are smarter together than we are on our own. Reviews from novices and newcomers are particularly valuable: it's easy for people who have been using these materials for a while to forget how impenetrable some of this material can be, so fresh eyes are always welcome.

Using GitHub

If you choose to contribute via GitHub, you may want to look at How to Contribute to an Open Source Project on GitHub. To manage changes, we follow GitHub flow. To use the web interface for contributing:

  1. Fork the originating repository to your GitHub profile.
  2. Within your version of the forked repository, move to the main branch and create a new branch for each significant change being made.
  3. Navigate to the file(s) you wish to change within the new branches and make revisions as required.
  4. Commit all changed files within the appropriate branches.
  5. Create individual pull requests from each of your changed branches to the main branch within the originating repository.
  6. If you receive feedback, make changes using your issue-specific branches of the forked repository and the pull requests will update automatically.
  7. Repeat as needed until all feedback has been addressed.

When starting work, please make sure your clone of the originating main branch is up-to-date before creating your own revision-specific branch(es) from there. Additionally, please only work from your newly-created branch(es) and not your clone of the originating main branch. Lastly, published copies of all the sections are available in the main branch of the originating repository for reference while revising.

Building

The user guide uses Sphinx, a Python documentation tool. You must have a recent version of Python 3.6+ installed to build the project locally. It is also recommended having make (otherwise look at the commands used in Makefile).

The dot program from Graphviz is needed to render some of the diagrams.

  • For Debian/Ubuntu users:
sudo apt-get install graphviz
# Create and activate a virtual environment
python3 -m venv venv
source venv/bin/activate
# update the version of pip, setuptools, and wheel
(venv) pip install -U pip setuptools wheel
# Install all the dependencies in your virtual environment.
(venv) pip install ".[all]"
# Create the HTML to visualize locally
(venv) make html
(venv) open _build/html/index.html
# Or you can start a serve that watches for local file changes
(venv) make watch
# Open <http://localhost:8000/> in your browser

You can use udocker or any other Docker compatible engine to build the user guide, by setting the following environment variable: CWLTOOL_OPTIONS=--udocker, or CWLTOOL_OPTIONS=--podman for Podman, or CWLTOOL_OPTIONS=--singularity for Singularity/Apptainer.

NOTE: When you modify the packages installed with apt or pip, please verify if the change needs to be applied to either or to both of CI and readthedocs. ReadTheDocs builds and deploys previews. CI builds and deploys production (GitHub Actions). Failing to update both may result in previews generated correctly, but failure to deploy the production version after the pull request gets merged.

Style Guide

We must use the phrase "CWL standards" or "CWL open standards" when talking about CWL. We must use the word "specification" only when talking specifically about the CWL specification document.

Whenever a page is updated we must verify that it does not break existing links, both internal and external. The make html command will fail if Sphinx detects broken links. It only works for links managed by Sphinx (i.e. table of contents links, or links to Markdown pages). For simple HTML links (e.g. < href=> or markdown external links) pull request reviewers must verify that links are still working after the change.

Use “tool description” not “tool wrapper” for describing the first argument given to the cwl-runner or cwltool commands.

Code Examples

All CWL documents should be version 1.2 unless there is a very good reason otherwise.

To include code into a Markdown file you have two options. For external files use the following command:

```{literalinclude} /_includes/cwl/hello_world.cwl
:language: cwl
```

For code examples in the same page, you can use fence blocks.

```bash
echo "Hello world"
```

If you would like to customize the syntax highlighting styles you will have to customize the Sphinx and Pygments settings. To preview Pygments output with different styles, use their Pygments demo tool.

Creating Links

Sphinx and the theme are configured to auto-generate anchor slug links for sections. So sections like ## cwl standard are translated into an anchor link #cwl-standard.

If you are having trouble with links to sections or code blocks, it might be due to duplicated sections, or to spaces or other characters. To preview the generated links, use the myst-anchors tool.

Troubleshooting

General advice for troubleshooting is to increase the verbosity of Sphinx logs. When using make, change your command to the following pattern: make SPHINXOPTS="-vvv" html. Or if you are using sphinx-build, then use the following: sphinx-build -vvv -b html src build/.

It is also worth removing build directories and files such as _build, build, and ~/.cache/salad. You may want to start afresh with a new Python virtual environment, installing the dependencies from scratch.

If running make html or make watch appears to run fine but gets stuck at some part of the process (10%, 33%, 57%, etc.) for longer than 2-5 minutes you may have to try the following:

  1. Check if the Python dependencies installed in your Python virtual environment have updates available (you can re-create the virtual environment, use --upgrade for pip, or manually verify in PyPI and pip).
  2. Use top or htop to find out if there is any cwltool command running. Then try running that command individually to see what is the error message.
  3. Upgrade your version of docker if you have an error message similar to docker: Failed to create the container ID file: open /tmp/....cid: no such file or directory..
  4. Try using udocker instead of docker, by using pip to install it, and setting CWLTOOL_OPTIONS to --udocker.

Other Resources

General discussion of Common Workflow Language project happens on the discussion mailing list, which everyone is welcome to join.