fedora-infrastructure

#10896 Greenwave ignores RemoteRule for Bodhi update
Closed: Fixed by kevin. Opened by mizdebsk.

Closed: Fixed
Reopen Issue

Bodhi updates can be pushed to stable before required gating tests passed. This can lead to broken packages to be delivered to end users. An example scenario is explained below.

An automatic Bodhi update FEDORA-2022-41a45c0285 has been created for Koji build xz-java-1.9-4.fc38.
The build was done from dist-git commit 8324ba9982a18d026b7e7b42e313c8ece5487909.
This commit adds a valid gating.yaml file that requires fedora-ci.koji-build./plans/javapackages.functional test case to pass before update can be submitted to stable.
Yet, Bodhi set update's test gating status to 'ignored' and then submitted it for stable, before test completed.
This is because, according to Greenwave, no tests are required for this update:

$ curl -s -X POST https://greenwave.fedoraproject.org/api/v1.0/decision -H 'Content-Type: application/json' -d '{"product_version": "fedora-38", "decision_context": "bodhi_update_push_stable", "subject_type": "koji_build", "subject_identifier": "xz-java-1.9-4.fc38"}' | jq
{
  "applicable_policies": [
    "kojibuild_bodhipush_no_requirements",
    "kojibuild_bodhipush_remoterule"
  ],
  "policies_satisfied": true,
  "satisfied_requirements": [],
  "summary": "no tests are required",
  "unsatisfied_requirements": []
}

Greenwave policy "kojibuild_bodhipush_remoterule" contains RemoteRule, which should translate to appropriate PassingTestCaseRule as configured in gating.yaml file, yet according to Greenwave, no tests are required.

An example update that was pushed to stable despite failing gating tests:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-abf6486c4a

Metadata Update from @zlopez:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: Needs investigation

@abompard Do you have any idea what is happening here?

@adamwill may have some insight here as well. ;)

I suspect this is caused by the following bug in Greenwave.
Greenwave prefers extra/source/original_url over source when obtaining SCM URL from which particular build was done.
This (incorrect) behavior is also covered by tests
Difference between build source and extra/source/original_url is documented in Koji:

      source: the SCM URL of the sources used in the build -
              dereferenced git hash is stored here
      extra: dictionary with extra data about the build
          - source:
              - original_url: while build.source contains concrete
                SCM hash, this field can contain SCM url which was
                used when launching build (e.g. git_url#master)

Basically, Greenwave should use source as it contains concrete commit hash.

In case of xz-java-1.9-4.fc38 build, source is:
git+https://src.fedoraproject.org/rpms/xz-java.git#8324ba9982a18d026b7e7b42e313c8ece5487909
while original_url is:
git+https://src.fedoraproject.org/rpms/xz-java.git#origin/rawhide
Edited by mizdebsk

Would you be willing to file this upstream?

Or @lholecek where would you like to track it?

 
      source: the SCM URL of the sources used in the build -
              dereferenced git hash is stored here
      extra: dictionary with extra data about the build
          - source:
              - original_url: while build.source contains concrete
                SCM hash, this field can contain SCM url which was
                used when launching build (e.g. git_url#master)

Oh, we currently expect the opposite to be true. 🤔

See: https://pagure.io/greenwave/issue/470

Fix: https://github.com/release-engineering/greenwave/pull/83

Great. I assume you can roll out a fixed version when it's ready?

Let me know if there's anything more to you need us to do here.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Great. I assume you can roll out a fixed version when it's ready?

Let me know if there's anything more to you need us to do here.

I have released a new Greenwave version. Can we tag the image (with "prod-fedora") for deployment to prod?

Prod and even stage is still seems to use a very old version 1.10.0:
- https://greenwave.fedoraproject.org/api/v1.0/about
- https://greenwave.stg.fedoraproject.org/api/v1.0/about

Would it be OK for stage to use "latest" image? Image tags are here: https://quay.io/repository/factory2/greenwave?tab=tags

Here is the changelog for the recent releases:
https://gating-greenwave.readthedocs.io/en/latest/release-notes.html

Sure, go ahead and tag it and I can run the playbooks to get it deployed.

Staging here has that issue where it's trying to layer a layer where it calls dnf, but the image no longer has dnf. I have it on my todo list to clean that up, but I haven't had a chance to ever get to it.
Feel free to submit a PR for it, or I can try and clean it up when I get to it. Once thats fixed, we can indeed run latest there if you like.

CC: @adamwill for visibility.

I'm all in favor of using the latest version (so long as nothing breaks), it'll fix a slightly annoying bug...

:thumbsup: Done, I've just tagged the latest image with "prod-fedora".

And here are the required changes for deployment: https://pagure.io/fedora-infra/ansible/pull-request/1219

Commit 40d4841b fixes this issue
Metadata
None

Needs investigation greenwave

None
None
Normal
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.