Rawhide gating is an initiative that spawns over a large number of applications, each having their own update cycle and for a large part being maintained by different teams.
While working on rawhide gating, we have written a couple of utility scripts that allowed us to do end to end testing of the packager workflow. For example one script does:
Clone a git repo Bump the release of the spec file (in the master branch) Commit Add a new git remote to the fork Push to the fork Open a PR for these changes in src.fedoraproject.org Checks that the PR is flagged with the “Fedora CI” flag: status: Running Checks that the PR is flagged with the “Fedora CI” flag: status: Failed (the tests in that specific git repo are not meant to pass) Merge the PR Build the package in koji Checks that the update was automatically created in bodhi Check that the build is signed (by checking its koji tags) Check that the CI pipeline is triggered Check that the CI pipeline completes (outcome: Failure) Check that greenwave’s decision is: NOGO Waive the failed test Check that waiverdb announced the new waiver Check that greenwave’s decision is: GO Check that the update is moved into rawhide (by check the koji tag of the build).
This is most helpful to figure out when and more precisely where something is not behaving as expected in the packager workflow. As such, we would like to run this script in an automated and regular way and use it as a mechanism to both monitor and debug the packager workflow.
To this end, we would like to request from FESCo the permission to create 3 packages and a bot account to be used to monitor the packager workflow.
1 package would be use to monitor the single build workflow the other 2 packages will made be tightly dependent (B-1.0.0-1 Requires: A-1.0.0-1 exactly) allowing to ensure that both packages are tested together a bot account (packagerbot?) would be used as the account doing the builds and updates. It will thus need to be sponsored in the packager group and be granted a keytab to automatically make the builds in koji.
For package name, I propose:
d3301aac-24d8-479b-ad34-1bdf66dae6b5 2b8af524-9dcd-48e7-b5b2-813ef1fa5682 9e341497-bbf4-4b48-9c52-b2aeaf17b5ac
They will each have a very simple tarball and spec file, installing a single file in /usr/share for example so that we can also ensure that integration with lookaside works as expected.
We already have all the ACLs we need to make this happen but we prefer to have FESCo’s blessing to do it.
Shouldn't the package names be more descriptive? Such as:
dummy-testing-package-d3301aac dummy-testing-package-2b8af524 dummy-testing-package-9e341497
I also think this should also have several constraints:
Yes, those constrains are reasonable. As I don't really care about names, dummy-testing-package-d3301aac is as good to me as d3301aac-24d8-479b-ad34-1bdf66dae6b5 :-)
dummy-testing-package-d3301aac
d3301aac-24d8-479b-ad34-1bdf66dae6b5
Could you share the spec files for reference?
If you want we can incorporate them in the distro via the package review process :)
Shouldn't the package names be more descriptive?
One of the reason for the uuid4 names was to lower the chances of showing these packages in dnf search results. That being said, I don't care about the names either.
dnf search
real license filed (Public Doman?)
Public domain isn't recognized in certain jurisdiction, I'm thinking more CC0
I propose to use this dummy python project: https://pagure.io/Fedora-Infra/dummy-package/ which comes with an example spec file: https://pagure.io/Fedora-Infra/dummy-package/blob/master/f/dummy-package.spec
The packages 1 and 2 would have this basically as is and we can then just add to the spec file of package 3:
Requires: <package2>-%{version}-%{release}
Why to make it a Python package? I suppose it will not interfere much with my work, but note that I'd be happier if the testing package had no semantic content at all.
This would also conflict if somebody ever wants to package https://pypi.org/project/dummy_package/ (very unlikely).
+1 with the constraints stated by @churchyard in https://pagure.io/fesco/issue/2300#comment-616308.
FTR I'm also +1 with my own constraints. I'd also gladly review the packages in terms of Package Review.
However, if somebody wants to discuss the package naming or a more general policy for this (I know for example @pingou uses fedora-gather-easyfix for testing) we can start a discussion on the devel mailing list.
I would prefer to call packages like fedora-ci-testing-package-1, fedora-ci-testing-package-2 and such. So that it is visible what it is used for.
fedora-ci-testing-package-1
fedora-ci-testing-package-2
Also we might need to add some filtering in pungi so that these packages do not end up on the mirrors.
Also please use very simple packages with like no files (unless you want to test that) so that we spend less resources building them.
Assuming the restrictions suggested by Miro and Igor (descriptive package name+summary+description, real License tag, no complicated dependency stuff, resource-usage-friendliness): +1
Why to make it a Python package?
As you can see the project was created on Friday in a few hours, just like for the rpm name, I don't really care about its name :) As for making it a python package, that's just because I'm somewhat biased to that ecosystem and it was easier for me to come up with a stupid tarball to would install an hello world script.
I'm fine with renaming the project as Igor suggested.
I want the simplest package but although as close to "the real thing" as possible. That's why i went with a dummy python package installing a hello world script.
@churchyard rather than keeping on discussing this on ticket, could you ping me on #fedora-devel when you have a minute so we can come back here with an agreed solution?
Will try to ping you tmrw. Feel free to ping me when you see me there.
Will try to ping you tmrw.
Sorry, I didn't make it.
So @churchyard and I met earlier today and we agreed on using canary's names (makes sense for canary testing right?) and use a basic/small tarball containing just a uuid file and its LICENSE file (CC0).
uuid
The package names are: - dummy-test-package-gloster - dummy-test-package-rubino - dummy-test-package-crested The first one will be used for single build gating and the other two for multi-builds gating.
The spec file is at: https://etherpad.gnome.org/p/dummy-test-package-gloster.spec
Looks good, minus some syntax errors in the .spec file (but I guess this is just a draft?)
Yes, it was drafted in the etherpad, never actually built. If you see obvious syntax error, feel free to fix it. Thanks.
Another formal +1 from me.
I think you fixed the one or two issues I saw in the meantime. So +1 from me :)
Since the overall response on this demand has been positive, I've created the first package review request.
https://bugzilla.redhat.com/1785278
We can use it as a basis to discuss if this is acceptable to FESCo and discuss on a concrete proposal.
The package has been reviewed and approved, but I'll wait for an official green light from FESCo before requesting the package creation.
We're at +3 if I'm counting correctly. We should wait for a full week for the vote to count.
Full week has happened. APPROVED (+3,0,-0).
We haven't talked about the bot username much. That might be bike-shedding really. So use whatever you want as long as it is deductible it as a testing bot. I trust @pingou knows how to get that account set up and who to talk to about it.
Metadata Update from @churchyard: - Issue tagged with: pending announcement
Thanks!
I was thinking packager-bot for the bot's name and yes, I know how to get that account setup :)
packager-bot
Announced.
Metadata Update from @psabata: - Issue untagged with: pending announcement - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.