Bug 2133878 - pep8 fails due to brackets after assert keyword
Summary: pep8 fails due to brackets after assert keyword
Keywords:
Status: POST
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-cliff
Version: 17.0 (Wallaby)
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: ---
Assignee: Szymon Datko
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-10-11 17:34 UTC by Szymon Datko
Modified: 2023-08-09 09:46 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:
Embargoed:
sdatko: needinfo-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 852177 0 None master: MERGED cliff: Removing brackets around tested conditional (I0a086a8349e2a72cae024857e148fddc3556c319) 2022-12-15 16:12:34 UTC
OpenStack gerrit 862494 0 None stable/wallaby: NEW cliff: Removing brackets around tested conditional (I0a086a8349e2a72cae024857e148fddc3556c319) 2022-12-15 16:12:40 UTC
Red Hat Issue Tracker OSP-19323 0 None None None 2022-10-11 17:50:41 UTC

Description Szymon Datko 2022-10-11 17:34:42 UTC
Hello,

we observe the following issue when running pep8 job in Component CI for OSP 17 and 17.1

```
cliff/tests/test_app.py:297:23: E275 missing whitespace after keyword
```

Indeed there is an issue in the mentioned line.

The problem was recently closed in upstream master:
https://review.opendev.org/c/openstack/cliff/+/852177

Can we have it cherry-picked to OSP 17 and OSP 17.1 code as well?

Yours, Szymon

Comment 1 Szymon Datko 2022-10-11 22:03:28 UTC
For now we proceed with a in-job workaround to make the job functional and voting: https://github.com/RedHatCRE/znoyder/pull/101
Tested here: https://code.engineering.redhat.com/gerrit/c/python-cliff/+/420536

When the proper change is cherry-picked to downstream, we will remove the workaround.

Comment 2 Jon Schlueter 2022-10-24 14:25:02 UTC
So one other thing to consider is if we have something out of sync with upstream since upstream pep8 job for stable/wallaby is either broken as well and we should fix there first or it is fine and we are doing something different from upstream stable/wallaby (17.1 and 17.0)

Comment 3 Szymon Datko 2022-12-15 16:24:58 UTC
> Jon Schlueter  2022-12-15 16:17:16 UTC
> Assignee: jschluet → sdatko

From Glossary:

  – Assignee
  ––– The person in charge of resolving the bug.

I only introduced a workaround, but I feel I have no power here to anything more. What else is expected?

Comment 4 Jon Schlueter 2022-12-15 21:30:42 UTC
So, at this point can we close fixed upstream? and if the change comes in we are good? 

or do we need to dig into why the linter job that we are using is complaining but the upstream linter job is not complaining about this existing code defect?

Comment 5 Szymon Datko 2022-12-15 23:32:35 UTC
As per the first comment, there is nothing to dig:

> The problem was recently closed in upstream master:
> https://review.opendev.org/c/openstack/cliff/+/852177

I can also see there was a cherry-pick to wallaby done in the meantime.
So, if the repos are synced, we are good.


Note You need to log in before you can comment on or make changes to this bug.