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
