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
Hi all,
I like this idea, I often miss Github's code search feature when working with repos on Pagure.
Cheers, Alex
On 8/25/21 8:30 PM, Ken Dreyer wrote:
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
koji-devel mailing list -- koji-devel@lists.fedorahosted.org To unsubscribe send an email to koji-devel-leave@lists.fedorahosted.org 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.fedorahosted.org/archives/list/koji-devel@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
As an old school open source devotee, I balk at moving from an foss solution to a proprietary one.
On Thu, Aug 26, 2021 at 9:11 AM Alex Iribarren alex.m.lists3@gmail.com wrote:
Hi all,
I like this idea, I often miss Github's code search feature when working with repos on Pagure.
Cheers, Alex
On 8/25/21 8:30 PM, Ken Dreyer wrote:
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
koji-devel mailing list -- koji-devel@lists.fedorahosted.org To unsubscribe send an email to koji-devel-leave@lists.fedorahosted.org 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.fedorahosted.org/archives/list/koji-devel@lists.fedorahosted.o...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
koji-devel mailing list -- koji-devel@lists.fedorahosted.org To unsubscribe send an email to koji-devel-leave@lists.fedorahosted.org 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.fedorahosted.org/archives/list/koji-devel@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Aug 26, 2021 at 11:10 AM Michael McLean mikem@redhat.com wrote:
As an old school open source devotee, I balk at moving from an foss solution to a proprietary one.
Likewise. I'd prefer we *didn't* use GitHub.com or GitLab.com because neither are FOSS solutions.
-- 真実はいつも一つ!/ Always, there's only one truth!
Hey all,
Was there any decision on this?
I am asking because the koji operator repository[1] is hosted in pagure as well and I think it makes sense for that project to be as close as possible to where koji is hosted as well.
[1] - https://pagure.io/kube-sig/koji-operator
On Thu, Aug 26, 2021 at 12:37 PM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Aug 26, 2021 at 11:10 AM Michael McLean mikem@redhat.com wrote:
As an old school open source devotee, I balk at moving from an foss
solution to a proprietary one.
Likewise. I'd prefer we *didn't* use GitHub.com or GitLab.com because neither are FOSS solutions.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ koji-devel mailing list -- koji-devel@lists.fedorahosted.org To unsubscribe send an email to koji-devel-leave@lists.fedorahosted.org 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.fedorahosted.org/archives/list/koji-devel@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Sep 29, 2021 at 9:17 AM Leonardo Rossetti lrossett@redhat.com wrote:
Hey all,
Was there any decision on this?
I am asking because the koji operator repository[1] is hosted in pagure as well and I think it makes sense for that project to be as close as possible to where koji is hosted as well.
There is no desire to move at this time.
koji-devel@lists.stg.fedorahosted.org