index.rst 6.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143
  1. Contributing
  2. ============
  3. Developing CodeRed CMS
  4. ---------------------------------
  5. To create a test project locally:
  6. #. Clone the code from https://github.com/coderedcorp/coderedcms.
  7. #. Run ``pip install -e ./[dev]`` from the root coderedcms directory. The -e flag makes the install editable,
  8. which is relevant when running makemigrations in test project to actually generate the migration
  9. files in the coderedcms pip package. The ``[dev]`` installs extras such as sphinx for generating docs.
  10. #. Follow the steps in :doc:`/getting_started/install`. Use "testproject" for
  11. your project name to ensure it is ignored by git.
  12. #. When making model or block changes within coderedcms, run ``makemigrations coderedcms`` in the
  13. test project to generate the relevant migration files for the pip package. ALWAYS follow steps
  14. 4 and 5 in :doc:`/getting_started/install` with a fresh database before making migrations.
  15. #. When model or block changes affect the local test project (i.e. the "website" app), run
  16. ``makemigrations website`` in the test project to generate the relevant migration files locally.
  17. Apply and test the migrations. When satisfied, re-generate the 0001_initial.py migration in
  18. ``project_template/website/migrations/`` as so:
  19. #. Create a new test project using ``coderedcms start testproject``.
  20. #. Before running migrations, DELETE all migrations in ``testproject/website/migrations/``.
  21. #. Run ``python manage.py makemigrations website``. This should generate an ``0001_initial.py``
  22. migration.
  23. #. Replace ``project_template/website/migrations/0001_initial.py`` with your newly generated migration.
  24. When making changes that are potentially destructive or backwards incompatible, increment the minor
  25. version number until coderedcms reaches a stable 1.0 release. Each production project that uses
  26. coderedcms should specify the appropriate version in its requirements.txt to prevent breakage.
  27. .. note:
  28. When testing existing projects with coderedcms installed from the master or development branches,
  29. be sure to use a disposable database, as it is likely that the migrations in master will
  30. not be the same migrations that get released.
  31. Testing CodeRed CMS
  32. -------------------
  33. To run the built in tests for CodeRed CMS, run the following in your test project's directory:
  34. ``python manage.py test coderedcms --settings=coderedcms.tests.settings``
  35. Adding New Tests
  36. ----------------
  37. Test coverage at the moment is fairly minimal and it is highly recommended that new features and models include proper unit tests.
  38. Any testing infrastructure (ie implementations of abstract models and migrations) needed should be added to the ``tests`` app in your
  39. local copy of CodeRed CMS. The tests themselves should be in their relevant section in CodeRed CMS (ie tests for
  40. models in ``coderedcms.models.page_models`` should be located in ``coderedcms.models.tests.test_page_models``).
  41. For example, here is how you would add tests for a new abstract page type, ``CoderedCustomPage`` that would live in ``coderedcms/models/page_models.py``:
  42. 1. Navigate to ``coderedcms/tests/testapp/models.py``
  43. 2. Add the following import: ``from coderedcms.models.page_models import CoderedCustomPage``
  44. 3. Implement a concrete version of ``CoderedCustomPage``, ie ``CustomPage(CoderedCustomPage)``.
  45. 4. Run ``python manage.py makemigrations`` to make new testing migrations.
  46. 5. Navigate to ``coderedcms/models/tests/test_page_models.py``
  47. 6. Add the following import: ``from coderedcms.models import CoderedCustomPage``
  48. 7. Add the following import: ``from coderedcms.tests.testapp.models import CustomPage``
  49. 8. Add the following to the bottom of the file:
  50. ::
  51. class CoderedCustomPageTestCase(AbstractPageTestCase, WagtailPageTests):
  52. model = CoderedCustomPage
  53. 9. Add the following to the bottom of the file:
  54. ::
  55. class CustomPageTestCase(ConcreteBasicPageTestCase, WagtailPageTests):
  56. model = CustomPage
  57. 10. Write any specific test cases that ``CoderedCustomPage`` and ``CustomPage`` may require.
  58. Contributor guidelines
  59. ----------------------
  60. We are happy to accept pull requests from the community if it aligns with our vision for coderedcms.
  61. When creating a pull request, please make sure you include the following:
  62. * A description in the pull request of what this change does and how it works.
  63. * Reference to an issue if the change is related to one of the issues on our GitHub page.
  64. * Documentation updates in the ``docs/`` directory describing your change.
  65. Following submission of your pull request, a CodeRed member will review and test your change.
  66. **All changes, even by CodeRed members, must go through a pull request process to ensure quality.**
  67. Building pip packages
  68. ---------------------
  69. To build a publicly consumable pip package, run::
  70. python setup.py sdist bdist_wheel
  71. Building documentation
  72. ----------------------
  73. For every code or feature change, be sure to update the docs in the repository. To build and publish
  74. the documentation run::
  75. cd docs/
  76. make clean
  77. make html
  78. Output will be in ``docs/_build/html/`` directory.
  79. Publishing a new release
  80. ------------------------
  81. First checkout the code/branch for release.
  82. Next build a pip package::
  83. python setup.py sdist bdist_wheel
  84. Then upload the pip package to pypi::
  85. twine upload dist/*
  86. Finally build and update docs::
  87. cd docs/
  88. make clean
  89. make html
  90. If updating docs for an existing minor version release:
  91. #. Copy the contents of ``docs/_build/html/`` to the CodeRed docs server under the existing version directory.
  92. If this is a new major or minor version release:
  93. #. Create a new major.minor directory on the CodeRed docs server.
  94. #. Update the ``stable`` symlink to point to the new version directory.
  95. #. Add the new version to the ``versions.txt`` file on the docs server.
  96. #. Copy the contents of ``docs/_build/html/`` to the CodeRed docs server under the new version directory.
  97. Note that we do not release separate documentation versions for maintenance releases. Update the existing minor
  98. version docs with release notes and other changes.