Re: The New Hotness 1.0.0 deployed on production

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 09. 12. 21 21:15, Miro Hrončok wrote:
On 09. 12. 21 18:34, Fabio Valentini wrote:
On Thu, Dec 9, 2021 at 2:57 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:

On 09. 12. 21 13:54, Michal Konecny wrote:
Hello everyone,

The New Hotness 1.0.0 is now live in Fedora infra production environment. For those who don't know what this app does, it basically notifying packagers about
new versions of packages by creating bugzilla issues.

And what is new:
* The New Hotness was rewritten from scratch using clean architecture design
(it's now easier to maintain and less error prone)
* Documentation[0] was updated to be more useful and up to date
* The comments created in bugzilla should be more helpful and contain info
about errors if any happens during the scratch build
* The New Hotness now remembers the Koji Task ID,even if there is error in post scratch build. In past the task ID was just lost and when the build was
finished The New Hotness couldn't recognize it
* We now have a containerized workflow for development

If you want to look at full changelog, please visit the-new-hotness GitHub
release page [1].

Awesome!

Let me use this as an opportunity to ask:
How can I disable reporting of pre-releases?

The only way I can think of to "ignore" pre-releases is to add a
"Version filter" on release-monitoring.org ...
I've started adding a "alpha;beta;rc;pre" filter (and set the
versioning to "semantic" to make sure they are sorted correctly) to
all Rust packages I touch, because we don't package pre-releases
except in rare circumstances.

Buuuut that only prevents anitya from fetching *new* pre-releases that
match that filter, it doesn't remove those that are already in the
database, and you won't get notifications for "new" versions that are
"older" than the latest pre-release :(

Hopefully for Python packages, this should be fixed in the future with:

https://github.com/fedora-infra/anitya/pull/1175

Maybe it can be solved similarly for Rust packages?
The New Hotness is still using RPM comparison for deciding if the version is newer than the old one regardless of how the versions are sorted in Anitya.

And in the future, The New Hotness will process all the new versions found by Anitya not only the newest one, this is why the anitya.project.version.update.v2 message topic was created. This is already prepared on Anitya side, but I still must implement it on The New Hotness side.

Michal
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux