Skip to content
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

test: udisks has CanResize everywhere now #19477

Conversation

jelly
Copy link
Member

@jelly jelly commented Oct 13, 2023

No description provided.

@jelly jelly added the no-test For doc/workflow changes, or experiments which don't need a full CI run, label Oct 13, 2023
All distributions we support have udisks 2.7 or higher.
@jelly jelly removed the no-test For doc/workflow changes, or experiments which don't need a full CI run, label Oct 13, 2023
@jelly jelly force-pushed the storaged-canresize-supported-filesystems-avaibility branch from 6bbde07 to 386556e Compare October 13, 2023 12:24
@jelly jelly marked this pull request as ready for review October 13, 2023 12:51
@jelly jelly changed the title test: check if we have CanResize everywhere test: udisks has CanResize everywhere now Oct 13, 2023
@jelly jelly requested a review from mvollmer October 13, 2023 12:51
@martinpitt
Copy link
Member

The anaconda workflow timed out waiting for the COPR build. This is almost surely because the source branch is behind cockpit:main. Your branch'es topmost commit is 386556e, which is what the workflow is waiting for. But the COPR was built for dac49423f , which doesn't appear anywhere. GitHub's marge commit as per API is 7cce69f, but apparently packit/COPR/etc. does a different merge (and possibly they are not reproducible). The srpm build does the merge:

2023-10-13 12:27:03.054 local_project.py  INFO   Checked out commit
(386556e7)	storaged: udisks supports CanResize since 2.7.2
2023-10-13 12:27:03.055 local_project.py  DEBUG  Target branch: main
2023-10-13 12:27:03.319 local_project.py  INFO   Merging (main) with commit:
(6f37c734)	test: Fix pytest race in test_spawn_broken_pipe()

But we absolutely have to do a version check there, as otherwise a force-push would immediately pick up the previous build. Time stamps may be an option -- according to this PR you pushed at 12:24 UTC, but the GH API head.repo.pushed_at claims "2023-10-13T13:17:23Z", while the COPR version 20231013122757 is again correct.

So instead I will explore https://issues.redhat.com/browse/COCKPIT-1071 to entirely avoid the polling.

In the meantime, it is fine to ignore this failed anaconda run.

Copy link
Member

@mvollmer mvollmer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, thanks!

@martinpitt martinpitt merged commit 5caea4b into cockpit-project:main Oct 16, 2023
100 of 101 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants