Bug 2133878

Summary: pep8 fails due to brackets after assert keyword
Product: Red Hat OpenStack Reporter: Szymon Datko <sdatko>
Component: python-cliffAssignee: Szymon Datko <sdatko>
Status: POST --- QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 17.0 (Wallaby)CC: jschluet
Target Milestone: ---Keywords: Triaged
Target Release: ---Flags: sdatko: needinfo-
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.