All CI used to go through scripts/generic-ci-tests.sh, which is a
wrapper around various `paver` test/linting/check invocations.
These days, most edx-platform CI checks just invoke their tools (pylint,
pycodestyle, pytest, etc.) directly.
In anticipation of the proposed Paver deprecation [1], let's remove
the parts of this script that aren't used any more, including several
`paver` command invocations. This should have no impact on CI.
Furthermore, we are able to remove the SHARD environment variable,
which was formely used to split unit and quality checks up into
smaller pieces. Unit tests and pylint checks now have their own
separate sharding logic, so there is only one "quality" shard remaining
(SHARD=4, ie generic quality checks), thus we don't need a SHARD
variable at all.
[1] https://github.com/openedx/edx-platform/issues/34467
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
