Currently, ./xmodule/ unit tests are only run with LMS settings. However,
./common/ and ./xmodule/ are run twice: once with LMS settings and once with
CMS settings.
Just like ./common/ and ./openedx/, the unit tests in ./xmodule/ validate
behavior in both LMS and CMS. So, order to fully test ./xmodule/, we should to
run its tests with CMS settings too.
This will enable us to better validate certain LibraryContentBlocks behaviors
being touched by https://github.com/openedx/edx-platform/pull/33263 which can't
be expressed under LMS settings.
Also in this commit:
* refactor: rename the shards to be clear whether they're running under LMS or CMS
* docs: correct comments regarding conditions under which codejail's
test_cant_do_something_forbidden is skipped.
* test: update a unit test which was using the now-deleted library_sourced block to use
library_content block instead.
I get a weekly CI failure email due to this scheduled workflow running on
my fork of edx-platform. Cancelling the job when it runs on a fork prevents
this.
This automation is not documented and has not been used in over seven
months. Remove references to it before we remove it from the
organization.
See https://github.com/openedx/axim-engineering/issues/898 for more
details.
I get a weekly CI failure due to having a fork of edx-platform. This
should stop that from happening.
Also:
- Dedent job name slightly so that the formatting is a little more standard
- Move the `uses` key up so that it's more obvious what's being called
This skips the `make compile-requirements` check when there have been
no changes under `requirements/**`, but it does so in a way that still
registers the action as having passed, not skipped. By doing so, we
can make it a required check while also avoiding the 5-6 minutes of
wasted worker time.
This commit also removes the activation on push-to-master, since we really
just need to check PRs. I don't expect there to be silent merge conflicts
with this check, so if it passes on a branch it should also pass on a
successful simple rebase or merge.
It would be nice if there was a way to declare success and exit early,
but GH hasn't implemented it: https://github.com/actions/runner/issues/662
Alternatively, it would be great if skipped checks could count as
fulfilling the branch protection rules, but no luck there.
The only alternative that uses GH's built-in paths/paths-ignore
feature would be to add a second workflow with the same job name and
the opposite path triggers and that always passes. It's not clear that
this would be any less fragile or confusing than the `git diff | grep`
and step-conditionals approach.
Adds a GH workflow that will run `make compile-requirements` and create
a PR for it and overhauls the requirements README with info on how to
use the new workflows.
README changes:
- Group the workflow/makefile info under a new heading
- Switch to imperative for headings
- Move "Upgrade all dependencies" to end of list (uncommon for people to
actually need this command, I suspect)
- Add "Add a dependency"
- Preamble about .in and .txt files and Mac vs. Linux, as well as about forks
Also, some style fixes to upgrade-one-python-dependency GH workflow:
- Fix indentation in inputs block
- Remove "-workflow" from job name (probably copied from another workflow)
- Wrap a long line
We have a few situations where requirements files can become
inconsistent or cause unnecessary review churn in later `make upgrade`
runs either due to manual editing, inconsistent environments, or
incorrectly specified git dependencies. This will produce a failing
check for any PR that does not produce a clean run of `make
compile-requirements` on Linux.
Addresses https://github.com/openedx/edx-platform/issues/31372
@feanil is overhauling the docs structure of edx-platform currently.
Recently, a change he made upped the docs build time from <15mins
to >40mins. Rather than revert the changes he is making, we're going
to take the docs build check out of CI for now. He plans to re-enable
the build check, but as a ReadTheDocs build, not a GitHub Action.
He's actively working on the docs, so he's not worried about any
regressions that may pop up while the check is disabled.
It's worth noting that the current docs check does not actually
publish its output anywhere.
Now that we're using standard service containers, we can use a matrix to
test both the current supported versions in one job. This should also
make it easier to test with future versions as we get ready to upgrade.
This will allow people to optionally describe the dependency upgrade
without having to rewrite the auto-generated commit or edit the PR body.
(The PR body isn't even guaranteed to make it into the eventual merged
commit.)
* feat: added enrollment API for notification config
* feat: added apps.py in notifications
* feat: added waffle flag for notification app
* feat: added proper docs for the API
This adds a Make target that should simplify the common task of
upgrading a single dependency. Sometimes people manually edit the pin
files, which we would like to avoid; hopefully this will make it
easier for them to do the right thing.
The GitHub workflow should also make it easier for people on Mac to
recompile requirements in a Linux environment, reducing the number of
times spurious dependency changes show up in the pin files (due to
OS-dependent requirements.)
Also, separate upgrade/downgrade instructions and simplify the latter.
(Min constraints are rare and we usually move beyond them quickly.)
