| Age | Commit message (Collapse) | Author |
|---|
|
I new there was something weird about these issues. They were due to
formatting changes but the seemed like ones that should have been taken
care of by the smudge filter. Turns out the issue was twofold:
1. there are some formatting changes that arise from running tools one
after the other, so that was resolved by running them all twice, so
they all get the change to run on each other's output
2. I think I typoed renormalize in my test script (s instead of z) which
made me think the option either did nothing or was on by default.
Much confusion.
|
|
I'm more interested in refining the strategies to deal with adapting to
whatever tools we choose to go with right now
|
|
It seems -X renormalize works from with merge. And I think more
consistently than rebasing? Not sure, need to go back and check after
the last round of fixes.
This just merges an auto-formatted merge-base branch into the PR, and
applies more autoformatting in the merge commit. It does not try to
merge the PR into a more recent base branch (which is what we want to do
with the open PRs). So it's not an answer yet but it might be the first
step in one.
Probably there could be more code de-duplicated between
merge_with_formatting and rebase_with_formatting.
TODO:
* look at merging into the more recent base instead of the temp one
* if that doesn't work see if we can rebase the merge commit up or
something after this initial formatting related merge
|
|
Weird, not sure where these empty files are coming from.
Also tell pyupgrade to always return 0 where nothing odd happens.
|
|
clean up temp files
always log the fail reason even if not pausing
|
|
Pyupgrade and black were fighting, which made this difficult to pin
down. #4578 was a good test case.
This makes it a bit slow now, of course.
|
|
TODO: look at merging instead of rebasing
|
|
Add a second argument to `maybepause()` to get it to pause working so
you can investigate in another terminal.
|
|
I'm seeing conflicts when trying to apply later commits that are
complaining about formatting changes made in earlier commits. In
particular the changes that are left in the working tree during a rebase
that are getting picked up by the "fix lint" commits.
I'm a little worried about this. For resolving those particular
conflicts -X theirs is the right thing to do, just take the new commit,
it already essentially replaces prior ones. But in cases where there is
a real conflict with master might we be obscuring that? Should be able
to test that.
TODO:
* look more into the cause of the "fix lint" commits, maybe even try
changing that to `reset HEAD` since those are just lint changes
* test if -X theirs will obscure real conflicts, look into some PRs to
see if it is doing weird stuff (I checked 7405 and 7312 already and
they look good!)
|
|
The cache for changes due to pyupgrade aren't the same from "pyupgrade"
as "black pyupgrade", so include the full set of commands in the cache
path.
Unfortunately that makes the cache less useful across different
configurations, but hopefully it still helps me when developing this.
|
|
Previously it was setting head_sha within the loop. When doing
rebase_with_formatting and that failed we weren't resetting to $base properly.
So it ended up trying to merge subsequent PRs onto previous ones, which caused
additional PRs to show as failed.
Change to save the base branch sha before we start doing work and just reset
at the top of the loop instead of trying to do it on each failure path.
|
|
It seems if you specify the same attribute multiple times in
gitattributes the last one wins. So on runs with multiple tools we were
only running the last one.
This switches to running all the tools from a shell script. Which is
written out from a shell script. I think there is probably a few more
cards we can stack on here before it all comes tumbling down.
TODO:
* why are we not seeing much of an improvement for the more complicated case,
weren't most of the conflicts in the first place from black?
report-black.csv succeeded=16 failed=58
report-tmp-black-rebase.csv succeeded=20 failed=9
report-black_isort_pyupgrade.csv succeeded=15 failed=59
report-tmp-black_isort_pyupgrade-rebase.csv succeeded=16 failed=13
|
|
See the comments in the script for more details. We are trying to see if
we can migrate PRs to be based off of a master branch that has had
autoformatting applied to it. Doing this via a merge is very difficult
because once you have conflict markers you can't really do much.
So you need to apply the autoformatters to the base branch and the PR
branch and then try to point the changed PR branch at the changed
master.
I tried doing it via a rebase first, which necessitates re-writing the
commits transparently when applying them. It seems to work well enough.
An initial one shows all of the PRs that applies successfully to master
applied to the changed master after going through this process.
I tried doing it via a rebase first because I find rebases easier to
reason about than merges. I did add a merge strategy too but it
performed poorly. I haven't put much thought into it and are probably
doing something wrong.
There's some duplication and hardcoded stuff. The tool "aliases" I moved
up because the re-writing is done in two places now. I'm hardcoding the
master report for excluding already-failing PRs, that might end up being
fine.
Next steps:
* verify this rebase strategy some more
* see how many fail when rebasing on qt6-v2 too
* look at the merge strategy again
* clean up the script more, consider porting it to python if the results
are anywhere near acceptable
|
|
One of the main issues remaining about the 3.0 release is what
autoformatters we can introduce to the codebase and how badly that'll
conflict with the open PRs. #1455
This is an attempt to provide some numbers to support that decisions. It
runs black and friends then tries to merge all the PRs.
The script needs updating to try some different merge strategies to see
if we can help people keep their PRs inline with the upcoming changes
without all having to be updated manually.
TODOs are at the bottom of the script.
|
|
|
|
The recent pytest 7.2 upgrade leads pylint to complain:
************* Module unit.browser.test_qutescheme
tests/unit/browser/test_qutescheme.py:26:0: I0021: Useless suppression of 'no-name-in-module' (useless-suppression)
tests/unit/browser/test_qutescheme.py:226:0: I0021: Useless suppression of 'no-member' (useless-suppression)
************* Module helpers.fixtures
tests/helpers/fixtures.py:39:0: I0021: Useless suppression of 'no-name-in-module' (useless-suppression)
tests/helpers/fixtures.py:639:0: I0021: Useless suppression of 'no-member' (useless-suppression)
possibly due to it not being able to infer 'py' anymore with the weird
shenanigans pytest does now?
Also, what weird glitch in the matrix is it that those just happen to be
on lines [2]26 and [6]39 for *both* files? 🤯
|
|
|
|
|
|
|
|
See https://github.com/cherrypy/cheroot/issues/517 and #7467
|
|
Got dropped from pytest-bdd: https://github.com/pytest-dev/pytest-bdd/pull/570
|
|
|
|
qutebrowser/dependabot/github_actions/peter-evans/create-pull-request-4
build(deps): bump peter-evans/create-pull-request from 3 to 4
|
|
Bumps [peter-evans/create-pull-request](https://github.com/peter-evans/create-pull-request) from 3 to 4.
- [Release notes](https://github.com/peter-evans/create-pull-request/releases)
- [Commits](https://github.com/peter-evans/create-pull-request/compare/v3...v4)
---
updated-dependencies:
- dependency-name: peter-evans/create-pull-request
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
|
|
See 78709ce2b9537f710f24edba15243aef1d732891
and fa5e04fdaf8af9230c4cd9c386c5d8e0307655ca
Hoping this will work better nowadays?
Tenatively closes #7299
|
|
Update dependencies
|
|
Newlines don't work anymore, see #7459
Partially reverts 0ff0eaa, see #7439
|
|
|
|
Fixes #7439
|
|
Update dependencies
|
|
|
|
|
|
See #6516
|
|
|
|
|
|
|
|
Not sure why this was a FIXME instead of handling it properly in the first place...
|
|
Update dependencies
|
|
Breaks tests...
This reverts commit fc933ae1d346d591c177b40693541d593b8f9a70.
|
|
Closes #7436
|
|
|
|
|
|
|
|
|
|
Update dependencies
|
|
See https://github.com/gforcada/flake8-deprecated/issues/19
|
|
|
|
https://github.com/ionelmc/pytest-benchmark/pull/224 was merged
|
|
Used to construct fully-qualified URLs from relative links. Without it
you get broken images and links.
|
|
See https://github.com/pytest-dev/pytest/pull/9118
|
