feat: add property for issue tracker status

[mfocko]

Add property to GitProject class that denotes whether issue tracker is
enabled on the specific project or not.

Signed-off-by: Matej Focko [email protected]

TODO:

• finish it off with the exception for disabled issue tracker

Fixes #664

RELEASE NOTES BEGIN
We have added a new property to git projects has_issues that indicates whether project has enabled issues or not. Following up on the property, create_issue now raises IssueTrackerDisabled when the project doesn't have issues enabled.
RELEASE NOTES END

[softwarefactory-project-zuul]

Build succeeded.

• pre-commit : SUCCESS in 5m 33s
• ogr-tests-rpm : SUCCESS in 9m 05s
• ogr-tests-pip-deps : SUCCESS in 9m 06s
• ogr-reverse-dep-packit-tests : SUCCESS in 15m 17s

[lachmanfrantisek]

Thanks! It's a really old one..;)

[mfocko]

@lachmanfrantisek Should I inspect the thrown exception or rather check .has_issues?

Positive for .has_issues is that I can do it right away at the start and be sure the issue is thrown for legitimate reasons and not guessed (e.g. 403 on GitLab).
Positive for thrown exception is that it doesn't create one more request to the API endpoint (to get the project settings).

[softwarefactory-project-zuul]

Build succeeded.

• pre-commit : SUCCESS in 3m 33s
• ogr-tests-rpm : SUCCESS in 6m 29s
• ogr-tests-pip-deps : SUCCESS in 6m 49s
• ogr-reverse-dep-packit-tests : SUCCESS in 13m 59s

[softwarefactory-project-zuul]

Build failed.

• pre-commit : SUCCESS in 4m 02s
• ogr-tests-rpm : FAILURE in 6m 51s
• ogr-tests-pip-deps : FAILURE in 6m 37s
• ogr-reverse-dep-packit-tests : SUCCESS in 16m 01s

[TomasTomecek]

neat

(I'm in favour of doing an extra request)

alternatively, in case of an issue, we could try checking in the exc handler - not sure if that's better

[softwarefactory-project-zuul]

Build succeeded.

• pre-commit : SUCCESS in 4m 20s
• ogr-tests-rpm : SUCCESS in 6m 27s
• ogr-tests-pip-deps : SUCCESS in 6m 13s
• ogr-reverse-dep-packit-tests : SUCCESS in 17m 06s

[softwarefactory-project-zuul]

Build succeeded (gate pipeline).

• pre-commit : SUCCESS in 3m 40s

[lachmanfrantisek]

@lachmanfrantisek Should I inspect the thrown exception or rather check .has_issues?

Positive for .has_issues is that I can do it right away at the start and be sure the issue is thrown for legitimate reasons and not guessed (e.g. 403 on GitLab). Positive for thrown exception is that it doesn't create one more request to the API endpoint (to get the project settings).

Do you mean here in the create_issue method or when using this elsewhere? But for both cases, I'm probably for the explicit checking of .has_issues. The code looks more readable to me (can be read as a sentence If has issues do something else do something different.)