feat: update 2u/main branch with new readme/docs (#228)

* feat: splitting master and 2u/main branches (#226)

* docs: update PR template

* docs: add ADR

* feat: remove pypi publish workflow for 2u/main

* feat: update 2u/main branch readme docs

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,10 +1,14 @@
+# ⛔️ MAIN BRANCH WARNING! 2U EMPLOYEES must make branches against the 2u/main BRANCH
+
+- [ ] I have checked the branch to which I would like to merge.
+
 # ⛔️ DEPRECATION WARNING
 
 **This repository is deprecated and in maintainence-only operation while we work on a replacement, please see [this announcement](https://discuss.openedx.org/t/deprecation-removal-ecommerce-service-depr-22/6839) for more information.**
 
 Although we have stopped integrating new contributions, we always appreciate security disclosures and patches sent to [[email protected]](mailto:[email protected])
 
-## Anyone internally merging to this repository is expected to [release and monitor their changes](https://openedx.atlassian.net/wiki/spaces/RS/pages/1835106870/How+to+contribute+to+our+repositories); if you are not able to do this DO NOT MERGE, please coordinate with someone who can to ensure that the changes are released.
+## If you're merging to master (not 2u/main) branch...
 
 **Merge checklist:**
 - [ ] Any new requirements are in the right place (do **not** manually modify the `requirements/*.txt` files)
@@ -23,6 +27,27 @@ Although we have stopped integrating new contributions, we always appreciate sec
     - This **must** be done after the version is visible in PyPi as `make upgrade` in ecommerce will look for the latest version in PyPi.
     - Note: the ecommerce-worker constraint in ecommerce **must** also be bumped to the latest version in PyPi.
 - [ ] Deploy `ecommerce`
+- [ ] Deploy `ecomworker`
+
+## If you're merging to 2u/main branch...
+
+You are expected to [release and monitor your changes](https://2u-internal.atlassian.net/wiki/spaces/RS/pages/7963261/How+to+contribute+to+our+repositories) (2U-private link); if you are not able to do this DO NOT MERGE, please coordinate with someone who can to ensure that the changes are released.
+
+**Merge checklist:**
+- [ ] Any new requirements are in the right place (do **not** manually modify the `requirements/*.txt` files)
+    - `base.in` if needed in production
+    - `test.in` for test requirements
+    - `make upgrade && make requirements` have been run to regenerate requirements
+- [ ] [Version](https://github.com/openedx/ecommerce-worker/blob/2u/main/ecommerce_worker/__init__.py) bumped
+
+**Post merge:**
+- [ ] Tag pushed and a new [version](https://github.com/openedx/ecommerce-worker/releases) released
+    - **Warning**: You must use 2u/main as the target release branch
+    - *Note*: You should prefix the tag with "2u/" (for example, "2u/3.3.4")
+    - *Note*: Assets will be added automatically. You just need to provide a tag (should match your version number) and title and description.
+- [ ] PR created in [ecommerce](https://github.com/openedx/ecommerce/tree/2u/main) **against 2u/main branch** to upgrade dependencies (including ecommerce-worker)
+    - Note: the ecommerce-worker constraint in ecommerce **must** also be bumped to the tag version you just released.
+- [ ] Deploy `ecommerce`
 - [ ] Deploy `ecomworker` on GoCD.
     - While some functions in ecommerce-worker are run via ecommerce, others are handled by a standalone AMI and must be
       released via GoCD.

.github/workflows/ci.yml

@@ -4,6 +4,7 @@ on:
   push:
     branches:
     - master
+    - 2u/main
     - /^\d+\.\d+(\.\d+)?(-\S*)?$/
   pull_request:
     branches:

README.rst

@@ -68,9 +68,11 @@ The code in this repository is licensed under the AGPL unless otherwise noted. P
 How To Contribute
 -----------------
 
-Anyone merging to this repository is expected to `release and monitor their changes <https://openedx.atlassian.net/wiki/spaces/RS/pages/1835106870/How+to+contribute+to+our+repositories>`__; if you are not able to do this DO NOT MERGE, please coordinate with someone who can to ensure that the changes are released.
+Notice: Internal 2U changes should be made against the ``2u/main`` branch.  Open source contributions should continue to be made against the ``master`` branch.
 
-Please also read `How To Contribute <https://github.com/openedx/.github/blob/master/CONTRIBUTING.md>`__.
+Anyone merging to the ``2u/main`` branch of this repository is expected to `release and monitor their changes <https://2u-internal.atlassian.net/wiki/spaces/RS/pages/7963261/How+to+contribute+to+our+repositories>`__ (2U-private link); if you are not able to do this DO NOT MERGE, please coordinate with someone who can to ensure that the changes are released.
+
+Please also read `How To Contribute <https://github.com/openedx/.github/blob/master/CONTRIBUTING.md>`__. Even though it was written with ``edx-platform`` in mind, these guidelines should be followed for Open edX code in general.
 
 Reporting Security Issues
 -------------------------

docs/decisions/0002-master-branch-split.rst

@@ -0,0 +1,65 @@
+2. Master branch split from 2u/main
+------------------------------------------------------------
+
+Status
+------
+
+Accepted
+
+Context
+-------
+
+Both 2U and the Open edX community used ecommerce-worker's master branch for releases. Occasionally, changes
+specific to 2U's business case are merged into code, which also influences the structure
+of the code that the community runs, even if the changes are not relevant or beneficial
+to the community at large.
+
+Additionally, 2U has internal compliance checks that can slow the release cycle of
+major changes to ecommerce-worker (for example, the upgrade to Django 4.2). This puts the Open edX community at risk of releasing
+with deprecated packages.
+
+Decision
+--------
+
+A new protected branch will be created named "2u/main", which 2U will continue to use
+as its own main branch, while leaving the "master" branch for use by the community.
+
+Consequences
+------------
+
+This allows the community to move forward with contributions on "master" without risk of
+breaking functionality for 2U or 2U committing changes to "master" that are irrelevant or
+otherwise inappropriate for the community's use case.
+
+Because protected branches in ecommerce-worker require a user with Write access to the repository,
+the "master" branch will now require someone from the community to review and manage
+code contributions to that branch.
+
+Additionally, changes pushed to the "2u/main" branch will not be published to PyPI. Tags will still be
+made for the "2u/main" branch, but to prevent version collisions with "master", they will be namespaced
+with "2u/", much like openedx releases are with "open-release/".
+
+Rejected Alternatives
+---------------------
+
+Publishing 2u/main ecommerce-worker to PyPI
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Packaging up the "2u/main" branch and publishing it to PyPI would preserve the
+current deployment strategy that 2U currently has internally; however, given that
+going forward the "2u/main"  branch is intended for internal use only, and PyPI is a
+place for public consumption, it no longer appropriate to follow this pattern, especially
+when there are other means of installing python requirements (namely, git urls and git tags).
+
+Repo fork
+~~~~~~~~~
+
+Why not fork the repo entirely? 2U and the community use a shared set of tools for
+working in development environments. While working from separate branches and repo
+forks are functionally equivalent, working in separate branches allows for
+minimal updates to shared tooling to support this change. One can simply checkout a
+branch name, without needing the tooling to be updated to know about non-openedx
+git remotes.
+
+This is not a one way door, and if we decide later the a proper repo fork is a better
+solution, then we are open to making adjustments.