This ticket got me thinking about integration testing recently:
https://pagure.io/koji/issue/2990
There were only two ways to catch that bug:
A) A human notices that the CLI uses new APIs without handling
GenericError/ParameterError
B) An automated test reports a failure
It's great if we can catch everything during a review, but deep
integration testing scales better. We also want to make it easier for
new contributors to add features, and automated tests would guide
those type of code changes more easily.
I've run Koji instances inside Travis CI and GitHub Actions for years
for the koji-ansible project. It's so critical to do live testing
against a real (throwaway) Koji instance. For example, this caught a
small API change recently:
https://github.com/ktdreyer/koji-ansible/issues/224
On distributed systems like Koji, it's important to bring up big
environments with many different permutations, test upgrades, etc.
I understand there is some CI for Koji with CentOS Jenkins right now,
but that infra does not get a lot of maintenance, and there are some
hard-to-debug failures.
Here are the reasons I suggest moving to GitHub instead:
GitHub is very fast
Many people have accounts already, so it's trivial for new contributors
It's very easy to run CI resources on pull requests
- Ken
Greetings Koji developers,
Some time ago I submitted a pull request to the koji repository [1].
Apparently, this action also subscribed me to some kind of CI
notifications. Now I receive many emails every day with subject like
"Build failed in Jenkins: koji ยป F33 #3088" that link to [2]. Getting
notifications about CI runs for my pull request would be good, but these
notifications are about something else. How can I unsubscribe?
Thank you!
Otto Urpelainen
[1]: https://pagure.io/koji/pull-request/2979
[2]: https://jenkins-fedora-infra.apps.ocp.ci.centos.org/job/koji/label=F33/
Koji 1.26.0 is out. Release is a bit smaller than usual as summer is in
full swing. But Thanks to everyone who contributed!
You can read release notes here:
https://docs.pagure.org/koji/release_notes/release_notes_1.26/
Highlights:
* SCM policy can now be defined at the hub via standard policy mechanism.
So, not that is now in the only place, but you can allow specific SCMs to
be used e.g. only for scratch builds. (#2757)
* Image builders can be configured to not verify SSL chain (#2797)
* getBuild API call now allows to get info about deleted tags (#1506)
* New policy test for build tag inheritance (#2870)
* Ability to enable/disabled/describe channels (#1711, #1849, #1850)
* Configurable name templates for sidetags (different families of
sidetags) (#2893)
* documentation updates
* 65 pull requests
You can view the 1.26 roadmap at https://pagure.io/koji/roadmap/1.26
For the current roadmap, see https://pagure.io/koji/roadmap
You can download this and other releases at https://pagure.io/koji/releases
--
Tomas Kopecek <tkopecek(a)redhat.com>
RHEL Build Development, RedHat
