Fixup some linking between documents in sphinx.

This commit is contained in:
John Chilton
2021-01-12 09:29:53 -05:00
parent 9bd66edc0b
commit f5648e2025
4 changed files with 6 additions and 5 deletions
+2 -2
View File
@@ -2,7 +2,7 @@
Galaxy is designed to run jobs on your local system by default, but it can be configured to run jobs on a cluster. The front-end Galaxy application runs on a single server as usual, but tools are run on cluster nodes instead.
A [general reference for the job configuration file](jobs.md) is also available.
A [general reference for the job configuration file](./jobs.md) is also available.
## Distributed Resources Managers
@@ -70,7 +70,7 @@ You may also find that attribute caching in your filesystem causes problems with
## Runner Configuration
**This documentation covers configuration of the various runner plugins, not how to distribute jobs to the various plugins.** Consult the [job configuration file documentation](jobs.md) for full details on the correct syntax, and for instructions on how to configure tools to actually use the runners explained below.
**This documentation covers configuration of the various runner plugins, not how to distribute jobs to the various plugins.** Consult the [job configuration file documentation](./jobs.md) for full details on the correct syntax, and for instructions on how to configure tools to actually use the runners explained below.
### Local
+1 -1
View File
@@ -399,7 +399,7 @@ these paths need to exposed in the same way.
You may find it useful to require authentication for access to certain paths on your server. For example, Galaxy can
run a separate reports app which gives useful information about your Galaxy instance. See the [Reports Configuration
documentation](reports) and [Peter Briggs' blog post on the
documentation](./reports) and [Peter Briggs' blog post on the
subject](http://galacticengineer.blogspot.com/2015/06/exposing-galaxy-reports-via-nginx-in.html) for more.
After successfully following the blog post, Galaxy reports should be available at e.g. `https://galaxy.example.org/reports`.
+2 -2
View File
@@ -438,8 +438,8 @@ separated, to the `job-handlers` farm. For example, 3 handlers are defined like
By default, a job will be handled by whatever mule currently has the lock on the mule message queue. After receiving a
message, it will release the lock, giving other mules a chance to handle future jobs. Jobs can be explicitly mapped to
specific mules as described in the [Job configuration documentation](jobs.md) by using the handler IDs
`main.job-handlers.N`, where `N` is the mule's position in the farm, starting at 1 and incrementing for each mule in the
specific mules as described in the [Galaxy Job Configuration](./jobs.md) documentation
by using the handler IDs `main.job-handlers.N`, where `N` is the mule's position in the farm, starting at 1 and incrementing for each mule in the
farm (this is not necessarily the mule ID, but it will be if you only define one farm and you add mules to that farm in
sequential order). Each worker that you wish to explicitly map jobs to should be defined in the `<handlers>` section
of `job_conf.xml`. *Do not* define a default handler.
@@ -10,6 +10,7 @@ Special Topics
interactive_environments
mulled_containers
grt
gtn
job_metrics
webhooks
performance_tracking