-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor project tree to handle multiple OpenEdx releases #112
Conversation
589d51d
to
acd296d
Compare
Oops, I forgot to update the docs (README). Will fix this soon. |
Another remark: I think we may factorize our configuration utility. |
As you are the CHANGELOG master, you should probably add one ? |
Last remark: what about adding a test in the CI that ensure that the build starts and we can query it? This is the least we can do IMO. |
You might want to update your PR description as some explanations are obsolete. |
@sampaccoud Can you point me where please? |
@jmaupetit it seems you have already added what is suggested in the note? |
We've checked out hawthorn.1 branch configuration and Dockerfile. We've also added a default fake SENTRY_DSN for development purpose. Fix #94
To ease working on a particular release, we've defined an activation script for each release (e.g. an activate script at the root of each release folder); the aforementioned script updates the working environment to target this release. We've also added an utility to assist / ease quick start activation: use bin/activate to list select release you want to work on.
We need our CI to build every release to prevent possible side-effects. When publishing a new image, we rebuild only a single release corresponding to the release tag.
We've checked out oee/hawthorn.1 branch configuration, Dockerfile, requirements and generated a patch from our edx-platform fork [1] to enable our customizable LTI Xblock. This allows us to explicitly store differences between a bare hawthorn.1 installation and our oee flavor. [1] https://github.com/openfun/edx-platform/commits/oee/hawthorn.1
lynx is required for courses indexation and bulk email generation.
A little revamp of the basic docs in the project.
When using raw docker-compose commands, the UID and GID environment variables are supposed to be defined. Hence, to avoid having a warning message (and potential errors), one should use the following command: UID=$(id -u) GID=$(id -g) docker-compose To ease our life, we've added a bin/compose script that can be used as a shortcut for a configured docker-compose command.
eaebdc3
to
a47a05e
Compare
@lunika I've added changelogs per release, you can check this out: https://github.com/openfun/openedx-docker/pull/112/files?file-filters%5B%5D=.md#diff-4ac32a78649ca5bdd8e0ba38b7006a1e |
Like other projects, we need to ensure that our CHANGELOGs and git commits fit with our expectations.
We've added a wait loop at the end of the "make run" and "make dev" commands to ensure that the database and core services are up before giving back the command prompt.
Development settings expect the sentry logger to be defined (meaning that Sentry is configured for this flavor/release). It is not by default.
fb51868
to
98a7ed1
Compare
Finally ready for another (last?) review @sampaccoud & @lunika 🙏 |
247b862
to
ac01898
Compare
When dealing with Django management commands, most of the time our servers are already running, meaning that we don't need to spawn a new stack and use the one that already runs.
To ensure that our production builds are able to start and respond with a HTTP requests we now start the CMS & LMS production services using docker-compose and use curl to test them.
ac01898
to
5c1fba0
Compare
Purpose
Managing multiple OpenEdx releases by using branches is a complicated workflow on a day to day basis. Once a new release (i.e. a branch for this project) has been created, it will no longer get rebased to
master
and backporting things is highly error-prone (one should not forget to do so for each release). Hence, in this context, we've decided to move to a simpler file-based tree to deal with releases.Proposal
We've decided to add all supported releases to the same
releases
directory:In this case, the
master
release in its "bare" flavor (i.e. as a freshedxapp
installation would be) has its own assets (Dockerfile
configuration, data and sources). Another example for thehawthorn.1
release would look like ("bare" and "oee" flavors):To work on a particular release, you will have to define the following environment variables:
EDX_RELEASE
(default:master/bare
): targeted OpenEdx release (e.g.hawthorn/1/oee
) that should match a path relative to thereleases
directoryEDX_RELEASE_REF
(default:release-2018-08-29-14.14
): this is the Git reference you are targeting from edx-platform repositoryEDX_DEMO_RELEASE_REF
: (default:master
) this is the Git reference you are targeting from edx-demo-course repositoryRoadmap
hawthorn.1
branch to the new architectureoee/hawthorn.1
branch to the new architectureactivate
script that defines them for each release (as we do with a python virtualenv), e.g.source releases/hawthorn/1/ooe/activate
move the(edit: postponed to a new PR as we need more work on it than checking out files from the related branch)dogwood-fun
branch to the new architectureFixes #66, #67, #94 , #110