The package version may not include the "-nightly" suffix. Otherwise,
`pip install .` fails with:
setuptools.extern.packaging.version.InvalidVersion: Invalid version: '...-nightly'
The package version number may not include the "-nightly" suffix.
Otherwise, installation fails with:
setuptools.extern.packaging.version.InvalidVersion: Invalid version: '15.0.7-nightly'
This is to address https://github.com/overhangio/tutor-mfe/issues/122
As a consequence of this change, images will be tagged with a "-nightly"
suffix. Next, we'll probably have to build them periodically in CI.
Here, we make it possible to add a "-nightly" suffix to the package
version. This suffix will find its way to the Docker image tags. Thus,
the nightly branch will have different image tags. This will resolve
some confusion, as image tags are currently identical in nightly and
master.
The Docker image now defaults to the tutor production settings, which allows us
to remove the environment variable from the docker-compose and k8s
configuration files.
Since we introduced `tutor dev quickstart`, we must be able to initialize the
discovery container in dev mode. The problem is that the "openedx" partner is
unavailable in dev mode. Thus, we need to default to the "dev" partner in dev
mode.
Close#33.
This ensures that services started with `tutor dev start`
are as capable for breakpoint debugging, et al, as services
started with `tutor dev runserver` are. We plan to remove
`tutor dev runserver`.
Patches related to nginx are removed and Caddy is now being used as a reverse proxy.
In addition, application log storage has been moved in order to run as
non-root. The local log handler was removed.
In Discovery, programs and courses are always associated to a site and partner.
However, sites differ in development and in production, because their urls are
different. And when we run the `cache_programs` in the LMS, we must be careful
to hit the url that corresponds to the right site in dev and prod. This url is
no longer defined by the COURSE_API_URL setting, or the internal_api_url
attribute. Instead, they are loaded from the corresponding site configuration.
To resolve this mess, we make sure that the right site configurations are
properly defined in dev and local.
It is the responsibility of end users to properly associate courses and
programs to the right site (dev or local) on their running platform...
How to reproduce the issue:
- Run the `create_catalog_integrations` command indicated in the readme.
- Create a program in discovery, and add a few courses to it. Make sure it is associated to the "Open edX" partner, and not "Open edX - dev".
- Run the `cache_programs` command from the readme
- Authenticate and open /dashboard/programs. The program you created should appear.
Add local nginx aliase to allow access discovery service through
discovery.local.overhang.io when running locally. One use case
is credentials service needs to access discovery api to pull catalogs.
