You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if someone makes changes to tox.ini directly without having them reflected in tox.jinja or the script, CI should fail so that we don't end up having a desynced state
regenerate tox.ini and compare hashes, see if there are differences between the committed and the generated tox.ini
this has to be a bit smarter and take into account when the script ran last -- it might happen that re-running the script introduces unrelated changes (because e.g. a new version of a framework was released in the meantime) and thus fails the check even if there were no changes made to tox.ini in the PR
save the timestamp of when tox.ini was last generated and committed, read this when regenerating for this check, and run the script ignoring any releases that came out after the timestamp
The text was updated successfully, but these errors were encountered:
Add `fail_on_changes` to toxgen. The idea is that the script will now
have two modes:
- **Normal mode** (when `fail_on_changes` is `False`) that is used to
actually generate the `tox.ini` file. This [will
be](#4050) run in a
cron job in CI and create a PR with the updated test setup.
- The newly added **fail-on-changes mode** (when `fail_on_changes` is
`True`) that is used to detect manual changes to one of the affected
files without updating the rest (e.g. making a manual change to
`tox.ini` without updating the `tox.jinja` template). This will be run
in CI similar to the `fail_on_changes` check of `split-tox-gh-actions`.
The problem with detecting manual changes is that if we just reran the
script on each PR, chances are it would pull in new releases that are
not part of the `tox.ini` on master, making the file look different from
what was committed as if it had unrelated manual changes.
To counteract this, we now store the timestamp when the file was last
generated in `tox.ini`. We use this in fail-on-changes mode to filter
out releases that popped up after the file was last generated. This way,
the package versions should be the same and if there is anything
different in `tox.ini`, it's likely to be the manual changes that we
want to detect.
Closes#4051
tox.ini
directly without having them reflected intox.jinja
or the script, CI should fail so that we don't end up having a desynced statetox.ini
and compare hashes, see if there are differences between the committed and the generatedtox.ini
tox.ini
in the PRtox.ini
was last generated and committed, read this when regenerating for this check, and run the script ignoring any releases that came out after the timestampThe text was updated successfully, but these errors were encountered: