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

copr list-packages report build status incorrectly #3564

Open
keszybz opened this issue Dec 24, 2024 · 4 comments
Open

copr list-packages report build status incorrectly #3564

keszybz opened this issue Dec 24, 2024 · 4 comments

Comments

@keszybz
Copy link
Contributor

keszybz commented Dec 24, 2024

I have a copr with a bunch of builds. Some succeeded, some failed, and some were started with a bad package name (subpackage not the main package). list-packages shows all builds as failed:

$ copr list-packages zbyszek/merged-sbin >/tmp/pkgs.merged-sbin.1
$ grep latest_ /tmp/pkgs.merged-sbin.1|sort|uniq -c
    664         "latest_build": null,
    664         "latest_succeeded_build": null,

list-builds shows 416 builds with "None" as the package name, and 613 builds with some package name. One package was built twice (abrt). But no matter which way you count, the number 664 doesn't seem to match any of that.

Am I holding it wrong?

@github-project-automation github-project-automation bot moved this to Needs triage in CPT Kanban Dec 24, 2024
@nikromen nikromen added bug and removed bug labels Jan 5, 2025
@nikromen
Copy link
Member

nikromen commented Jan 5, 2025

hi, copr list-package has --with-latest-build and --with-latest-succeeded-build. This way you can display these

$ copr list-packages --help
usage: copr list-packages [-h] [--with-latest-build] [--with-latest-succeeded-build] [--with-all-builds]
                          [--output-format {text,json,text-row}]
                          copr

positional arguments:
  copr                  The copr repo to list the packages of. Can be just name of project or even in format owner/project.

options:
  -h, --help            show this help message and exit
  --with-latest-build   Also display data related to the latest build for the package.
  --with-latest-succeeded-build
                        Also display data related to the latest succeeded build for the package.
  --with-all-builds     Also display data related to the builds for the package.
  --output-format {text,json,text-row}
                        Set the formatting style. We recommend using json, which prints the required data in json format. The text format
                        prints the required data in a column, one piece of information per line. The text-row format prints all
                        information separated by a space on a single line.

@praiskup
Copy link
Member

praiskup commented Jan 6, 2025

The latest_* fields are very confusing in my opinion, shall we just hide those by default?

Otherwise @nikromen is right, you need to use the corresponding --with-latest* option to have the fields returned by packages' api.

list-builds shows 416 builds with "None" as the package name, and 613 builds with some package name

The name: None field implies that Copr wasn't able to realize the build's package name. Practically it means the build failed in some early stage, probably when getting sources from Fedora DistGit. The failure ratio is huge in your case though; the DistGit method should almost never fail 🤷 any idea what was happening? Wasn't there some src.f.o outage? The logs are unfortunately garbage-collected already.

@keszybz
Copy link
Contributor Author

keszybz commented Jan 6, 2025

I think that in JSON output, it's unexpected to have fields with bogus data (null). JSON is extensible, so I would expect the fields to either be present with the real values or not present.

The name: None field implies that Copr wasn't able to realize the build's package name.

Yeah, I messed up the script to start the builds. This is entirely on my side, no fault of copr.

@FrostyX
Copy link
Member

FrostyX commented Jan 6, 2025

shall we just hide those by default?

I am not against this if we consider this to be a bug. Just a warning that it would break API backward compatibility. People may have something like this in their scripts:

from copr.v3 import Client
client = Client.create_from_config_file()
package = client.package_proxy.get("@copr", "copr-dev", "copr-cli")
if package.builds["latest_succeeded"]:
    ...

Which would traceback now and they would need to use package.builds.get("latest_succeeded"), or maybe even checking if the builds field exist.

@praiskup praiskup moved this from Needs triage to In 2 years in CPT Kanban Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In 2 years
Development

No branches or pull requests

4 participants