diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 1b4fadfe..cd2f555c 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.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 [security@edx.org](mailto:security@edx.org) -## 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. diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index e0eba3fc..a5e4fe83 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -4,6 +4,7 @@ on: push: branches: - master + - 2u/main - /^\d+\.\d+(\.\d+)?(-\S*)?$/ pull_request: branches: diff --git a/.github/workflows/pypi-publish.yml b/.github/workflows/pypi-publish.yml deleted file mode 100644 index 977a3a2c..00000000 --- a/.github/workflows/pypi-publish.yml +++ /dev/null @@ -1,30 +0,0 @@ -name: Publish to PyPI - -on: - release: - types: [published] - -jobs: - - push: - runs-on: ubuntu-20.04 - - steps: - - name: Checkout - uses: actions/checkout@v2 - - name: setup python - uses: actions/setup-python@v2 - with: - python-version: 3.8 - - - name: Install pip - run: pip install setuptools wheel - - - name: Build package - run: python setup.py sdist bdist_wheel - - - name: Publish to PyPI - uses: pypa/gh-action-pypi-publish@release/v1 - with: - user: __token__ - password: ${{ secrets.PYPI_UPLOAD_TOKEN }} diff --git a/README.rst b/README.rst index 35554e8f..741a18bc 100644 --- a/README.rst +++ b/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 `__; 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 `__. +Anyone merging to the ``2u/main`` branch of this repository is expected to `release and monitor their changes `__ (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 `__. Even though it was written with ``edx-platform`` in mind, these guidelines should be followed for Open edX code in general. Reporting Security Issues ------------------------- diff --git a/docs/decisions/0002-master-branch-split.rst b/docs/decisions/0002-master-branch-split.rst new file mode 100644 index 00000000..6939e861 --- /dev/null +++ b/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.