-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce new method get_latest_build #58
base: main
Are you sure you want to change the base?
Conversation
f5717f0
to
1c94d7a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor typo in git commit message s/interucting/interacting/, rest is fine
This seems somewhat tied to SUSE's conception of builds. In Fedora, for instance, builds are never really sortable, or only sortable within very specific constraints. This is why the webUI has the option to sort builds by the time they were created, which we always use in Fedora. If we're going to merge this it might be nice if it could similarly sort the builds by creation time, though I'm not sure off the top of my head whether the API exposes that information conveniently. |
actual name of configuration option which you mean here is
https://openqa.opensuse.org/api/v1/job_groups/1/build_results has |
1c94d7a
to
43ae687
Compare
fixed in both actual commit message and here in PR description |
Oh, yes, that's right, I forgot the details. Honestly, sorting by the time the build first showed up would be better for us, both in the web UI and here. But it may require work on upstream openQA, I'm not sure.
Yes, it does have this drawback, but it's much less bad than sorting "build names" like the ones in https://openqa.fedoraproject.org/group_overview/2 alphanumerically :D In practice, it is indeed the build for which a job was most recently created that comes on top of the list, i.e. it'd be X if you restarted the X job after you triggered Y. |
sure I can do that . but I see two options :
|
fully agree here , sorting should be done not by oldest job but by youngest this would make more sense . And yes before we can follow this approach here some work needs to be done in openQA backend ... |
I think we actually have a ticket about improving the time-based sorting in openQA to consider the first jobs in that build (so re-triggering jobs will not change the order). It was not clear whether this is problematic because it was not clear whether it conflicts with @AdamWill 's use case so we even considered making this a 3rd option. However, it actually seems to support @AdamWill 's use case so we could change the existing time-based sorting and avoid adding a 3rd option. Unfortunately I cannot find that ticket at the moment. |
that would be https://progress.opensuse.org/issues/57335 |
@AdamWill if you don't see further issues blocking feel welcome to merge |
tests/test_client.py
Outdated
def test_get_latest_build(self, fakerequest): | ||
client = oqc.OpenQA_Client() | ||
with pytest.raises(TypeError): | ||
client.get_latest_build() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why this? are we just checking how Python behaves when a call is missing a required argument? do we really...need to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH it does not make sense to me too , but I was just trying to following same logic used by other tests here . Should I also delete same pattern in lines 368-369 ?
with pytest.raises(TypeError):
client.get_jobs()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have that there because get_jobs
is kinda 'special'. All its arguments are optional, syntactically speaking. Python itself won't raise TypeError
if you do get_jobs()
. But we actually need you to pass either the jobs
arg or the build
arg, and if you don't pass either of those, we (that is, openQA-python-client) raise TypeError
- that's line 364 in client.py. Because that code is in our library it needs test coverage.
I actually hate this and wish I hadn't built it that way, but we're stuck with it now. :P
so yeah, leave test_get_jobs
alone, but remove the check from this PR. It's not needed here, since it's not our code that raises TypeError
here, so we don't need to test it. We're just relying on completely standard Python behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
er...but...you didn't remove the check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just first wrote then did the push , sorry . NOW it is done
group_id (int): Job Group ID | ||
all_passed (bool, optional): Controls whether just last build will be selected | ||
or the last with all jobs passed. Defaults to True. | ||
sorted_key (Callable, optional): To find the latest build we need to order the builds. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really like the name sorted_key
, the past tense is odd. I'd call it sort_key
. The description is a bit odd, it doesn't really explain that this is specifically the key used to sort the results.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The description is a bit odd, it doesn't really explain that this is specifically the key used to sort the results.
The specified callback will be used in the sorted function to sort builds
🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe just The specified callable will be passed to sorted() to sort the builds.
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it doesn't look like it's done? i still see the original text, "sorted_key (Callable, optional): To find the latest build we need to order the builds."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are too fast :) I am tweaking code in my working copy and marking conversation done so I know that I solved this one . After I go through ALL long list of endless discussions in this PR I am doing the push . This create a gap in 20 minutes between I wrote "done" and you can actually can confirm that . I was not expecting that you will get to the PR so fast , sorry . NOW it is done
5fb2941
to
0a1521c
Compare
@AdamWill I would kindly ask you to press "Resolve conversation" in discussions where you find problem solved so I can follow up on what is left |
just because this called my attention today when goigh through my gh notifications, doesn't the webUI already implements that? i.e see the test distribution and how it uses it ( nvm, just realized that it still depends on very smelly jq 😭 https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/.github/workflows/openqa.yml#L32 )' |
0a1521c
to
0eec4bd
Compare
|
0eec4bd
to
1e9e27e
Compare
One of many common tasks which you need to address when interacting with openQA programatically is to detect what was latest build in certain Job Group. This is implementation of such function in this lib, so users of this lib may delete same logic duplicated many times
1e9e27e
to
1f635b6
Compare
ahhh right, that was the thing, for TW the latest published build was the thing that the jq par does. |
One of many common tasks which you need to address when interacting
with openQA programatically is to detect what was latest build in certain
Job Group. This is implementation of such function in this lib, so
users of this lib may delete same logic duplicated many times