2014-02-12 05:23:40 -05:00
|
|
|
Path = require('path')
|
|
|
|
http = require('http')
|
|
|
|
http.globalAgent.maxSockets = 300
|
|
|
|
|
|
|
|
# Make time interval config easier.
|
|
|
|
seconds = 1000
|
|
|
|
minutes = 60 * seconds
|
|
|
|
|
|
|
|
# These credentials are used for authenticating api requests
|
|
|
|
# between services that may need to go over public channels
|
|
|
|
httpAuthUser = "sharelatex"
|
|
|
|
httpAuthPass = "password"
|
|
|
|
httpAuthUsers = {}
|
|
|
|
httpAuthUsers[httpAuthUser] = httpAuthPass
|
|
|
|
|
|
|
|
sessionSecret = "secret-please-change"
|
|
|
|
|
2016-06-17 09:22:20 -04:00
|
|
|
module.exports = settings =
|
2017-10-18 08:04:37 -04:00
|
|
|
|
|
|
|
allowAnonymousReadAndWriteSharing:
|
|
|
|
process.env['SHARELATEX_ALLOW_ANONYMOUS_READ_AND_WRITE_SHARING'] == 'true'
|
|
|
|
|
|
|
|
|
2014-02-12 05:23:40 -05:00
|
|
|
# File storage
|
|
|
|
# ------------
|
|
|
|
#
|
|
|
|
# ShareLaTeX stores binary files like images in S3.
|
|
|
|
# Fill in your Amazon S3 credential below.
|
|
|
|
s3:
|
|
|
|
key: ""
|
|
|
|
secret: ""
|
|
|
|
bucketName : ""
|
|
|
|
|
2014-03-05 06:22:52 -05:00
|
|
|
|
2014-02-12 05:23:40 -05:00
|
|
|
# Databases
|
|
|
|
# ---------
|
|
|
|
mongo:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url : process.env['MONGO_URL'] || "mongodb://#{process.env['MONGO_HOST'] or '127.0.0.1'}/sharelatex"
|
2014-02-12 05:23:40 -05:00
|
|
|
|
|
|
|
redis:
|
|
|
|
web:
|
2017-11-23 11:01:32 -05:00
|
|
|
host: process.env['REDIS_HOST'] || "localhost"
|
|
|
|
port: process.env['REDIS_PORT'] || "6379"
|
2014-02-12 05:23:40 -05:00
|
|
|
password: ""
|
|
|
|
|
2016-11-08 10:32:36 -05:00
|
|
|
# websessions:
|
|
|
|
# cluster: [
|
|
|
|
# {host: 'localhost', port: 7000}
|
|
|
|
# {host: 'localhost', port: 7001}
|
|
|
|
# {host: 'localhost', port: 7002}
|
|
|
|
# {host: 'localhost', port: 7003}
|
|
|
|
# {host: 'localhost', port: 7004}
|
|
|
|
# {host: 'localhost', port: 7005}
|
|
|
|
# ]
|
|
|
|
|
2016-12-19 07:17:58 -05:00
|
|
|
# ratelimiter:
|
|
|
|
# cluster: [
|
|
|
|
# {host: 'localhost', port: 7000}
|
|
|
|
# {host: 'localhost', port: 7001}
|
|
|
|
# {host: 'localhost', port: 7002}
|
|
|
|
# {host: 'localhost', port: 7003}
|
|
|
|
# {host: 'localhost', port: 7004}
|
|
|
|
# {host: 'localhost', port: 7005}
|
|
|
|
# ]
|
|
|
|
|
2017-05-09 06:40:42 -04:00
|
|
|
# cooldown:
|
|
|
|
# cluster: [
|
|
|
|
# {host: 'localhost', port: 7000}
|
|
|
|
# {host: 'localhost', port: 7001}
|
|
|
|
# {host: 'localhost', port: 7002}
|
|
|
|
# {host: 'localhost', port: 7003}
|
|
|
|
# {host: 'localhost', port: 7004}
|
|
|
|
# {host: 'localhost', port: 7005}
|
|
|
|
# ]
|
|
|
|
|
2014-02-12 05:23:40 -05:00
|
|
|
api:
|
2017-11-23 11:01:32 -05:00
|
|
|
host: process.env['REDIS_HOST'] || "localhost"
|
|
|
|
port: process.env['REDIS_PORT'] || "6379"
|
2014-02-12 05:23:40 -05:00
|
|
|
password: ""
|
|
|
|
|
|
|
|
# Service locations
|
|
|
|
# -----------------
|
|
|
|
|
|
|
|
# Configure which ports to run each service on. Generally you
|
|
|
|
# can leave these as they are unless you have some other services
|
|
|
|
# running which conflict, or want to run the web process on port 80.
|
|
|
|
internal:
|
|
|
|
web:
|
|
|
|
port: webPort = 3000
|
2017-11-23 11:01:32 -05:00
|
|
|
host: process.env['LISTEN_ADDRESS'] or 'localhost'
|
2014-02-12 05:23:40 -05:00
|
|
|
documentupdater:
|
|
|
|
port: docUpdaterPort = 3003
|
|
|
|
|
|
|
|
# Tell each service where to find the other services. If everything
|
|
|
|
# is running locally then this is easy, but they exist as separate config
|
|
|
|
# options incase you want to run some services on remote hosts.
|
|
|
|
apis:
|
|
|
|
web:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url: "http://#{process.env['WEB_HOST'] or 'localhost'}:#{webPort}"
|
2014-02-12 05:23:40 -05:00
|
|
|
user: httpAuthUser
|
|
|
|
pass: httpAuthPass
|
|
|
|
documentupdater:
|
2017-11-23 11:01:32 -05:00
|
|
|
url : "http://#{process.env['DOCUPDATER_HOST'] or 'localhost'}:#{docUpdaterPort}"
|
2014-02-12 05:23:40 -05:00
|
|
|
thirdPartyDataStore:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url : "http://#{process.env['TPDS_HOST'] or 'localhost'}:3002"
|
2014-02-12 05:23:40 -05:00
|
|
|
emptyProjectFlushDelayMiliseconds: 5 * seconds
|
|
|
|
tags:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url :"http://#{process.env['TAGS_HOST'] or 'localhost'}:3012"
|
2014-02-12 05:23:40 -05:00
|
|
|
spelling:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url : "http://#{process.env['SPELLING_HOST'] or 'localhost'}:3005"
|
2014-05-06 07:35:27 -04:00
|
|
|
trackchanges:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url : "http://#{process.env['TRACK_CHANGES_HOST'] or 'localhost'}:3015"
|
2017-10-11 06:18:34 -04:00
|
|
|
project_history:
|
2017-12-15 11:11:16 -05:00
|
|
|
sendProjectStructureOps: process.env.PROJECT_HISTORY_ENABLED == 'true' or false
|
|
|
|
initializeHistoryForNewProjects: process.env.PROJECT_HISTORY_ENABLED == 'true' or false
|
2018-01-03 11:29:28 -05:00
|
|
|
displayHistoryForNewProjects: process.env.PROJECT_HISTORY_ENABLED == 'true' or false
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url : "http://#{process.env['PROJECT_HISTORY_HOST'] or 'localhost'}:3054"
|
2014-04-30 06:33:31 -04:00
|
|
|
docstore:
|
2017-11-23 11:01:32 -05:00
|
|
|
url : "http://#{process.env['DOCSTORE_HOST'] or 'localhost'}:3016"
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
pubUrl: "http://#{process.env['DOCSTORE_HOST'] or 'localhost'}:3016"
|
2014-02-12 05:23:40 -05:00
|
|
|
chat:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url: "http://#{process.env['CHAT_HOST'] or 'localhost'}:3010"
|
|
|
|
internal_url: "http://#{process.env['CHAT_HOST'] or 'localhost'}:3010"
|
2014-02-12 05:23:40 -05:00
|
|
|
blog:
|
|
|
|
port: 3008
|
2014-10-08 11:07:44 -04:00
|
|
|
university:
|
|
|
|
url: "http://localhost:3011"
|
2014-02-12 05:23:40 -05:00
|
|
|
filestore:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url: "http://#{process.env['FILESTORE_HOST'] or 'localhost'}:3009"
|
2014-02-12 05:23:40 -05:00
|
|
|
clsi:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url: "http://#{process.env['CLSI_HOST'] or 'localhost'}:3013"
|
2014-08-20 09:47:27 -04:00
|
|
|
templates:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url: "http://#{process.env['TEMPLATES_HOST'] or 'localhost'}:3007"
|
2014-09-08 09:19:24 -04:00
|
|
|
githubSync:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url: "http://#{process.env['GITHUB_SYNC_HOST'] or 'localhost'}:3022"
|
2014-08-20 09:47:27 -04:00
|
|
|
recurly:
|
|
|
|
privateKey: ""
|
|
|
|
apiKey: ""
|
|
|
|
subdomain: ""
|
2014-10-13 09:10:15 -04:00
|
|
|
geoIpLookup:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url: "http://#{process.env['GEOIP_HOST'] or 'localhost'}:8080/json"
|
2015-03-09 10:09:09 -04:00
|
|
|
realTime:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url: "http://#{process.env['REALTIME_HOST'] or 'localhost'}:3026"
|
2015-10-07 12:32:35 -04:00
|
|
|
contacts:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url: "http://#{process.env['CONTACTS_HOST'] or 'localhost'}:3036"
|
2015-11-11 18:18:25 -05:00
|
|
|
sixpack:
|
|
|
|
url: ""
|
2016-06-24 10:03:15 -04:00
|
|
|
# references:
|
|
|
|
# url: "http://localhost:3040"
|
2016-08-05 10:15:56 -04:00
|
|
|
notifications:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url: "http://#{process.env['NOTIFICATIONS_HOST'] or 'localhost'}:3042"
|
2017-12-21 08:51:52 -05:00
|
|
|
analytics:
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
url: "http://#{process.env['ANALYTICS_HOST'] or 'localhost'}:3050"
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2014-08-20 09:47:27 -04:00
|
|
|
templates:
|
|
|
|
user_id: process.env.TEMPLATES_USER_ID or "5395eb7aad1f29a88756c7f2"
|
2015-04-13 06:29:59 -04:00
|
|
|
showSocialButtons: false
|
|
|
|
showComments: false
|
2014-02-12 05:23:40 -05:00
|
|
|
|
2016-08-23 11:46:23 -04:00
|
|
|
# cdn:
|
|
|
|
# web:
|
|
|
|
# host:"http://nowhere.sharelatex.dev"
|
2016-07-21 14:06:53 -04:00
|
|
|
# darkHost:"http://cdn.sharelatex.dev:3000"
|
2016-07-18 09:05:07 -04:00
|
|
|
|
2014-02-12 05:23:40 -05:00
|
|
|
# Where your instance of ShareLaTeX can be found publically. Used in emails
|
|
|
|
# that are sent out, generated links, etc.
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
siteUrl : siteUrl = process.env['PUBLIC_URL'] or 'http://localhost:3000'
|
2014-02-12 05:23:40 -05:00
|
|
|
|
2014-09-01 18:15:38 -04:00
|
|
|
# cookie domain
|
2015-11-24 11:53:44 -05:00
|
|
|
# use full domain for cookies to only be accessible from that domain,
|
|
|
|
# replace subdomain with dot to have them accessible on all subdomains
|
2014-08-04 11:47:14 -04:00
|
|
|
# cookieDomain: ".sharelatex.dev"
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
cookieName: "sharelatex.sid"
|
2014-08-04 11:47:14 -04:00
|
|
|
|
2016-04-20 10:06:39 -04:00
|
|
|
# this is only used if cookies are used for clsi backend
|
|
|
|
#clsiCookieKey: "clsiserver"
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2014-02-12 05:23:40 -05:00
|
|
|
# Same, but with http auth credentials.
|
|
|
|
httpAuthSiteUrl: 'http://#{httpAuthUser}:#{httpAuthPass}@localhost:3000'
|
|
|
|
|
2016-02-29 08:05:17 -05:00
|
|
|
|
2016-03-09 10:53:03 -05:00
|
|
|
maxEntitiesPerProject: 2000
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2014-02-12 05:23:40 -05:00
|
|
|
# Security
|
|
|
|
# --------
|
|
|
|
security:
|
|
|
|
sessionSecret: sessionSecret
|
2016-06-17 08:50:32 -04:00
|
|
|
bcryptRounds: 12 # number of rounds used to hash user passwords (raised to power 2)
|
2014-02-12 05:23:40 -05:00
|
|
|
|
|
|
|
httpAuthUsers: httpAuthUsers
|
|
|
|
|
|
|
|
# Default features
|
|
|
|
# ----------------
|
|
|
|
#
|
|
|
|
# You can select the features that are enabled by default for new
|
|
|
|
# new users.
|
2014-02-22 05:50:59 -05:00
|
|
|
defaultFeatures: defaultFeatures =
|
|
|
|
collaborators: -1
|
|
|
|
dropbox: true
|
|
|
|
versioning: true
|
2016-09-06 06:41:14 -04:00
|
|
|
compileTimeout: 180
|
2014-10-13 10:42:11 -04:00
|
|
|
compileGroup: "standard"
|
2016-01-19 08:37:11 -05:00
|
|
|
references: true
|
|
|
|
templates: true
|
2017-02-13 05:50:32 -05:00
|
|
|
trackChanges: true
|
2014-02-22 05:50:59 -05:00
|
|
|
|
2014-02-12 05:23:40 -05:00
|
|
|
plans: plans = [{
|
|
|
|
planCode: "personal"
|
|
|
|
name: "Personal"
|
|
|
|
price: 0
|
2014-02-22 05:50:59 -05:00
|
|
|
features: defaultFeatures
|
2014-02-12 05:23:40 -05:00
|
|
|
}]
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2016-10-12 12:35:40 -04:00
|
|
|
enableSubscriptions:false
|
2014-02-12 05:23:40 -05:00
|
|
|
|
2014-08-05 06:15:17 -04:00
|
|
|
# i18n
|
|
|
|
# ------
|
2016-11-08 10:32:36 -05:00
|
|
|
#
|
2014-08-05 06:15:17 -04:00
|
|
|
i18n:
|
2014-08-07 12:03:47 -04:00
|
|
|
subdomainLang:
|
|
|
|
www: {lngCode:"en", url: siteUrl}
|
|
|
|
defaultLng: "en"
|
2014-08-05 06:15:17 -04:00
|
|
|
|
2014-02-12 05:23:40 -05:00
|
|
|
# Spelling languages
|
|
|
|
# ------------------
|
|
|
|
#
|
2016-11-08 10:32:36 -05:00
|
|
|
# You must have the corresponding aspell package installed to
|
2014-02-12 05:23:40 -05:00
|
|
|
# be able to use a language.
|
|
|
|
languages: [
|
2014-06-25 08:51:02 -04:00
|
|
|
{name: "English", code: "en"},
|
|
|
|
{name: "French", code: "fr"}
|
2014-02-12 05:23:40 -05:00
|
|
|
]
|
|
|
|
|
2015-04-28 12:39:35 -04:00
|
|
|
|
|
|
|
# Password Settings
|
|
|
|
# -----------
|
|
|
|
# These restrict the passwords users can use when registering
|
|
|
|
# opts are from http://antelle.github.io/passfield
|
2016-10-03 06:33:14 -04:00
|
|
|
# passwordStrengthOptions:
|
|
|
|
# pattern: "aA$3"
|
|
|
|
# length:
|
2017-07-24 06:06:47 -04:00
|
|
|
# min: 6
|
|
|
|
# max: 128
|
2015-04-28 12:39:35 -04:00
|
|
|
|
2014-03-12 07:43:36 -04:00
|
|
|
# Email support
|
|
|
|
# -------------
|
|
|
|
#
|
|
|
|
# ShareLaTeX uses nodemailer (http://www.nodemailer.com/) to send transactional emails.
|
|
|
|
# To see the range of transport and options they support, see http://www.nodemailer.com/docs/transports
|
|
|
|
#email:
|
|
|
|
# fromAddress: ""
|
|
|
|
# replyTo: ""
|
|
|
|
# lifecycle: false
|
|
|
|
## Example transport and parameter settings for Amazon SES
|
|
|
|
# transport: "SES"
|
|
|
|
# parameters:
|
|
|
|
# AWSAccessKeyID: ""
|
|
|
|
# AWSSecretKey: ""
|
|
|
|
|
|
|
|
|
2014-02-12 05:23:40 -05:00
|
|
|
# Third party services
|
|
|
|
# --------------------
|
|
|
|
#
|
|
|
|
# ShareLaTeX's regular newsletter is managed by Markdown mail. Add your
|
|
|
|
# credentials here to integrate with this.
|
|
|
|
# markdownmail:
|
|
|
|
# secret: ""
|
|
|
|
# list_id: ""
|
|
|
|
#
|
|
|
|
# Fill in your unique token from various analytics services to enable
|
|
|
|
# them.
|
|
|
|
# analytics:
|
|
|
|
# ga:
|
|
|
|
# token: ""
|
2016-11-08 10:32:36 -05:00
|
|
|
#
|
2014-02-12 05:23:40 -05:00
|
|
|
# ShareLaTeX's help desk is provided by tenderapp.com
|
|
|
|
# tenderUrl: ""
|
|
|
|
#
|
2014-12-12 08:58:07 -05:00
|
|
|
# Client-side error logging is provided by getsentry.com
|
|
|
|
# sentry:
|
|
|
|
# src: ""
|
|
|
|
# publicDSN: ""
|
|
|
|
#
|
|
|
|
# src should be either a remote url like
|
2015-09-30 05:40:20 -04:00
|
|
|
# //cdn.ravenjs.com/1.1.22/jquery,native/raven.min.js
|
2014-12-12 08:58:07 -05:00
|
|
|
# or a local file in the js/libs directory.
|
|
|
|
# The publicDSN is the token for the client-side getSentry service.
|
2014-02-12 05:23:40 -05:00
|
|
|
|
|
|
|
# Production Settings
|
|
|
|
# -------------------
|
|
|
|
|
|
|
|
# Should javascript assets be served minified or not. Note that you will
|
|
|
|
# need to run `grunt compile:minify` within the web-sharelatex directory
|
|
|
|
# to generate these.
|
CI and local dev environment improvements
The need for this became very noticeable due to the slowness of filesystem access in docker-in-mac, with a full compile taking over a minute for me in docker. Using make to introduce incremental compile makes this near instantaneous outside of docker (if only a few files have changed), and quick enough inside docker.
With incremental compile via make, it compiles quickly enough that re-compiling and restarting the web service automatically when backend files change is quick enough now. This is how the service is run via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, so it shouldn't be necessary to manually restart the container each time a coffee file changes.
At the moment Jenkins pull web modules in via the GitSCM plugin, but I believe this is creating a dependency in Jenkins, where any commits to any of the modules causes all of the web branches to rebuild. By doing it via our own scripts we can hopefully avoid this. It also creates a build process which is reproducible locally.
**Note that at the moment in this PR all modules pull from `ja-dockerize-dev` branches, but these should be merged first, and this PR updated to point to the master branches before merging**. This is necessary for other changes to build process/docker-compose workflow.
As well as a Makefile for web, there is now a `Makefile.module`. This is copied into each module directory by the top-level Makefile, and is written in a way to be flexible and support unit tests, acceptance tests, front-end js for the ide and main, and the modules `app/coffee` directory, while allowing modules to have some of these missing (not all modules have e.g. acceptance tests, or front-end JS). This will allows us to refine the build process in future, without needing to update the Makefile in each module repo separately (I found this to be a painful part of this development).
This makes web compatible with the docker-compose workflow at https://github.com/sharelatex/sharelatex-dev-environment, where each service is running in its own docker container, with networking managed by docker.
Previously the Makefile was set up to run unit tests in docker with `make unit_tests`. This now just runs them natively. In the CI, they are run in docker anyway (all steps in Jenkins are), and locally, they run fine natively with `npm run test:unit`, or can be run in docker via https://github.com/sharelatex/sharelatex-dev-environment with `bin/run web_sl npm run test:unit`.
Previously we did a lot of juggling with only mounting source files (coffee, less, etc) into the docker container for acceptance tests. This was to avoid creating root owned files if the whole directory was mounted. Now instead the whole web directory is mounted read-only, with the compilation step done outside of the container before running the tests.
This allows the host and container to share the `node_modules` folder as well, which avoids needing to `npm install` twice on the CI box, and should speed up the build by a few minutes.
On macOS, this would cause a problem with compiled modules if you tried to use the same `node_modules` to run the app natively. However, if running via docker-compose in https://github.com/sharelatex/sharelatex-dev-environment, this is no longer a problem.
2017-12-28 15:11:27 -05:00
|
|
|
useMinifiedJs: process.env['MINIFIED_JS'] == 'true' or false
|
2014-02-12 05:23:40 -05:00
|
|
|
|
|
|
|
# Should static assets be sent with a header to tell the browser to cache
|
|
|
|
# them.
|
|
|
|
cacheStaticAssets: false
|
|
|
|
|
|
|
|
# If you are running ShareLaTeX over https, set this to true to send the
|
|
|
|
# cookie with a secure flag (recommended).
|
|
|
|
secureCookie: false
|
|
|
|
|
2014-06-25 05:34:23 -04:00
|
|
|
# If you are running ShareLaTeX behind a proxy (like Apache, Nginx, etc)
|
|
|
|
# then set this to true to allow it to correctly detect the forwarded IP
|
|
|
|
# address and http/https protocol information.
|
|
|
|
behindProxy: false
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2015-04-14 08:04:29 -04:00
|
|
|
# Cookie max age (in milliseconds). Set to false for a browser session.
|
|
|
|
cookieSessionLength: 5 * 24 * 60 * 60 * 1000 # 5 days
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2016-12-20 04:54:42 -05:00
|
|
|
# When true, only allow invites to be sent to email addresses that
|
|
|
|
# already have user accounts
|
|
|
|
restrictInvitesToExistingAccounts: false
|
|
|
|
|
2015-04-15 06:14:38 -04:00
|
|
|
# Should we allow access to any page without logging in? This includes
|
|
|
|
# public projects, /learn, /templates, about pages, etc.
|
2016-03-15 10:14:33 -04:00
|
|
|
allowPublicAccess: if process.env["SHARELATEX_ALLOW_PUBLIC_ACCESS"] == 'true' then true else false
|
2016-06-30 04:43:09 -04:00
|
|
|
|
|
|
|
# Use a single compile directory for all users in a project
|
|
|
|
# (otherwise each user has their own directory)
|
2016-06-30 10:15:37 -04:00
|
|
|
# disablePerUserCompiles: true
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2015-11-06 07:51:43 -05:00
|
|
|
# Maximum size of text documents in the real-time editing system.
|
|
|
|
max_doc_length: 2 * 1024 * 1024 # 2mb
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2014-02-12 05:23:40 -05:00
|
|
|
# Internal configs
|
|
|
|
# ----------------
|
|
|
|
path:
|
|
|
|
# If we ever need to write something to disk (e.g. incoming requests
|
|
|
|
# that need processing but may be too big for memory, then write
|
|
|
|
# them to disk here).
|
2014-05-15 11:32:17 -04:00
|
|
|
dumpFolder: Path.resolve __dirname + "/../data/dumpFolder"
|
|
|
|
uploadFolder: Path.resolve __dirname + "/../data/uploads"
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2014-02-12 05:23:40 -05:00
|
|
|
# Automatic Snapshots
|
|
|
|
# -------------------
|
|
|
|
automaticSnapshots:
|
2016-11-08 10:32:36 -05:00
|
|
|
# How long should we wait after the user last edited to
|
2014-02-12 05:23:40 -05:00
|
|
|
# take a snapshot?
|
|
|
|
waitTimeAfterLastEdit: 5 * minutes
|
|
|
|
# Even if edits are still taking place, this is maximum
|
|
|
|
# time to wait before taking another snapshot.
|
|
|
|
maxTimeBetweenSnapshots: 30 * minutes
|
|
|
|
|
|
|
|
# Smoke test
|
|
|
|
# ----------
|
|
|
|
# Provide log in credentials and a project to be able to run
|
|
|
|
# some basic smoke tests to check the core functionality.
|
|
|
|
#
|
|
|
|
# smokeTest:
|
|
|
|
# user: ""
|
|
|
|
# password: ""
|
|
|
|
# projectId: ""
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2015-03-09 08:14:30 -04:00
|
|
|
appName: "ShareLaTeX (Community Edition)"
|
2015-03-18 12:20:26 -04:00
|
|
|
adminEmail: "placeholder@example.com"
|
2017-08-07 11:01:59 -04:00
|
|
|
|
|
|
|
brandPrefix: "" # Set to 'ol-' for overleaf styles
|
2014-06-20 16:35:42 -04:00
|
|
|
|
|
|
|
nav:
|
2015-02-05 11:56:35 -05:00
|
|
|
title: "ShareLaTeX Community Edition"
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2014-06-20 16:35:42 -04:00
|
|
|
left_footer: [{
|
2016-01-04 06:12:10 -05:00
|
|
|
text: "Powered by <a href='https://www.sharelatex.com'>ShareLaTeX</a> © 2016"
|
2014-06-20 16:35:42 -04:00
|
|
|
}]
|
|
|
|
|
|
|
|
right_footer: [{
|
2015-02-05 11:56:35 -05:00
|
|
|
text: "<i class='fa fa-github-square'></i> Fork on Github!"
|
2014-06-20 16:35:42 -04:00
|
|
|
url: "https://github.com/sharelatex/sharelatex"
|
|
|
|
}]
|
|
|
|
|
2017-01-11 05:27:38 -05:00
|
|
|
showSubscriptionLink: false
|
|
|
|
|
|
|
|
header_extras: []
|
|
|
|
# Example:
|
|
|
|
# header_extras: [{text: "Some Page", url: "http://example.com/some/page", class: "subdued"}]
|
2016-07-14 06:40:32 -04:00
|
|
|
|
|
|
|
customisation: {}
|
|
|
|
|
2014-08-18 13:26:47 -04:00
|
|
|
# templates: [{
|
|
|
|
# name : "cv_or_resume",
|
|
|
|
# url : "/templates/cv"
|
|
|
|
# }, {
|
2014-08-18 13:35:16 -04:00
|
|
|
# name : "cover_letter",
|
|
|
|
# url : "/templates/cover-letters"
|
|
|
|
# }, {
|
|
|
|
# name : "journal_article",
|
|
|
|
# url : "/templates/journals"
|
|
|
|
# }, {
|
|
|
|
# name : "presentation",
|
|
|
|
# url : "/templates/presentations"
|
|
|
|
# }, {
|
|
|
|
# name : "thesis",
|
|
|
|
# url : "/templates/thesis"
|
|
|
|
# }, {
|
|
|
|
# name : "bibliographies",
|
|
|
|
# url : "/templates/bibliographies"
|
|
|
|
# }, {
|
|
|
|
# name : "view_all",
|
|
|
|
# url : "/templates"
|
2014-08-18 13:26:47 -04:00
|
|
|
# }]
|
2014-08-18 12:59:34 -04:00
|
|
|
|
2014-07-01 09:25:32 -04:00
|
|
|
|
2014-07-01 10:44:12 -04:00
|
|
|
redirects:
|
|
|
|
"/templates/index": "/templates/"
|
2014-07-01 09:25:32 -04:00
|
|
|
|
2014-07-01 11:00:42 -04:00
|
|
|
proxyUrls: {}
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2014-10-08 10:57:56 -04:00
|
|
|
reloadModuleViewsOnEachRequest: true
|
2015-02-20 07:09:35 -05:00
|
|
|
|
2015-05-22 08:57:15 -04:00
|
|
|
domainLicences: [
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2015-05-22 08:57:15 -04:00
|
|
|
]
|
|
|
|
|
2015-10-27 07:37:11 -04:00
|
|
|
sixpack:
|
2015-11-02 11:28:30 -05:00
|
|
|
domain:""
|
2015-02-20 07:09:35 -05:00
|
|
|
# ShareLaTeX Server Pro options (https://www.sharelatex.com/university/onsite.html)
|
|
|
|
# ----------
|
|
|
|
|
|
|
|
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2015-11-17 11:27:29 -05:00
|
|
|
# LDAP
|
|
|
|
# ----------
|
|
|
|
# Settings below use a working LDAP test server kindly provided by forumsys.com
|
|
|
|
# When testing with forumsys.com use username = einstein and password = password
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2015-10-22 05:42:50 -04:00
|
|
|
# ldap :
|
2015-02-26 06:40:02 -05:00
|
|
|
# host: 'ldap://ldap.forumsys.com'
|
2015-10-22 05:42:50 -04:00
|
|
|
# dn: 'uid=:userKey,dc=example,dc=com'
|
|
|
|
# baseSearch: 'dc=example,dc=com'
|
|
|
|
# filter: "(uid=:userKey)"
|
2015-02-26 06:40:02 -05:00
|
|
|
# failMessage: 'LDAP User Fail'
|
|
|
|
# fieldName: 'LDAP User'
|
2016-04-28 12:21:07 -04:00
|
|
|
# placeholder: 'email@example.com'
|
2015-02-26 06:40:02 -05:00
|
|
|
# emailAtt: 'mail'
|
2015-10-22 05:42:50 -04:00
|
|
|
# anonymous: false
|
2016-11-08 10:32:36 -05:00
|
|
|
# adminDN: 'cn=read-only-admin,dc=example,dc=com'
|
2015-11-19 06:52:11 -05:00
|
|
|
# adminPW: 'password'
|
2016-04-06 10:32:08 -04:00
|
|
|
# starttls: true
|
|
|
|
# tlsOptions:
|
|
|
|
# rejectUnauthorized: false
|
2016-04-15 13:46:11 -04:00
|
|
|
# ca: ['/etc/ldap/ca_certs.pem']
|
2016-11-08 10:32:36 -05:00
|
|
|
|
2015-05-10 08:10:03 -04:00
|
|
|
#templateLinks: [{
|
|
|
|
# name : "CV projects",
|
|
|
|
# url : "/templates/cv"
|
|
|
|
#},{
|
|
|
|
# name : "all projects",
|
|
|
|
# url: "/templates/all"
|
|
|
|
#}]
|
2017-10-09 11:31:01 -04:00
|
|
|
|
|
|
|
rateLimits:
|
|
|
|
autoCompile:
|
|
|
|
everyone: 100
|
|
|
|
standard: 25
|