- User Since
- Nov 12 2013, 2:18 PM (184 w, 3 d)
Pull request here: https://github.com/fedora-infra/fmn/pull/197
Here's a FMN pull request I intend to send:
Not only I renamed depcheck to rpmdeplint, but I also added abicheck as an important task to automatically notify people on failure. We don't get any false negatives reports, it's pretty important, and currently runs just on critical path packages. Abicheck authors have been asking for increased visibility for some time. Does it make sense, do you agree?
@tflink added you into taskotron group, please try again
Tue, May 23
OK. I also removed type=bodhi_update reporting, because we want to get rid of it, and this change is the best chance to push it forward (in the worst case, I'll also prepare a bodhi patch). Now we're waiting for beta freeze to be lifted so that we can push this to production. Also, I'll look at necessary FMN changes and bodhi changes.
Our documentation links to https://repos.fedorapeople.org/repos/tflink/phabricator/ . I can change that, but kanarip's packages don't work with our Phab instance:
$ arc list Exception [cURL/77] (https://phab.qa.fedoraproject.org/api/user.whoami) <CURLE_SSL_CACERT_BADFILE> The SSL CA Bundles that we tried to use could not be read or are not formatted correctly. (Run with `--trace` for a full exception trace.)
$ arc list --trace ARGV '/usr/share/arcanist/bin/../scripts/arcanist.php' 'list' '--trace' LOAD Loaded "phutil" from "/usr/share/libphutil/src". LOAD Loaded "arcanist" from "/usr/share/arcanist/src". Config: Reading user configuration file "/home/kparal/.arcrc"... Config: Did not find system configuration at "/etc/arcconfig". Working Copy: Reading .arcconfig from "/home/kparal/devel/taskotron/libtaskotron/.arcconfig". Working Copy: Path "/home/kparal/devel/taskotron/libtaskotron" is part of `git` working copy "/home/kparal/devel/taskotron/libtaskotron". Working Copy: Project root is at "/home/kparal/devel/taskotron/libtaskotron". Config: Did not find local configuration at "/home/kparal/devel/taskotron/libtaskotron/.git/arc/config". >>>  <conduit> user.whoami() <bytes = 117> >>>  <http> https://phab.qa.fedoraproject.org/api/user.whoami <<<  <http> 297,727 us <<<  <conduit> 297,936 us
Mon, May 22
So, here's my most awesome proposal - let's use this for now:
Once we also start checking repoclosure with it, we can extend it to
dist.rpmdeplint dist.rpmdeplint.sat dist.rpmdeplint.repoclosure
Which means dist.rpmdeplint would be the overall outcome of .sat and .repoclosure.
D1178 has been pushed and seems to be working well. This problem has been therefore solved for #task-rpmdeplint. Closing the ticket. The problem is still valid for task-depcheck, now we just need to finish T878 and get rid of depcheck.
This is working well in develop, pushing to master as well.
I understand the motivation - being able to transfer the task between different test systems without any changes. What I don't understand is how localhost-only ansible execution is related here. When I execute a task through ansible locally, and when I execute it remotely from a different machine, doesn't it look the same to the task itself? Is there a different environment or some behavioral changes that the task needs to adapt to? If the execution looks the same to the task regardless of ansible mode, the end goal is achieved (the task doesn't need to be adjusted when moving between test systems), and the particular ansible execution mode then can be left to the test system to implement as it fits best for it.
Fri, May 19
- add libvirt-python to readme instead, require fixed testcloud from pypi
OK, so, testcloud deps were fixed in D1200 and pushed to pypi.
Thu, May 18
Ah, good catch. The actual problem was with missing libvirt-python. That's a dependency of testcloud, but it clearly doesn't state it on the pypi package. So, we should add the dep to the testcloud package (I'll create a patch). The drawback is that libvirt-python is a bit problematic to install from pypi, it requires to compile some libvirt modules, so it might be actually easier to install it as an rpm anyway. Will look into it.
- fix running sphinx-build from virtualenv and use better approach to add stylesheet (the old one fails with newer sphinx)
Wed, May 17
Tue, May 16
So, first things first - I think there should be almost no deletions in this code. Our old system (formula and minion-based) will have to co-exist with the new system (ansible based) for some time, until we convert all our existing tasks to the new one, and iron out all issues. We need to keep compatibility for some time, this is probably a too big jump to switch everything over at the same time. I'd say keep all the existing code in place, just add new code to make ansible-based workflow work. Once both systems are deployed and working and once we covert all tasks to the new system, then we can drop the old code and refactor all the modules. This approach will also help in having the ansible feature branch much simpler, easier to compare and easier to rebase against develop.
Mon, May 15
Tue, May 9
There are already rules named A particular package and A particular user's packages in Generic Rules section. So it shouldn't be needed for us to add any more Taskotron-specific rules. You just combine some generic rules with a few taskotron rules and you're done. Am I missing something?
Apr 24 2017
Apr 21 2017
I can confirm this is now working. No need for modularity-testing-framework workaround anymore. Thanks, @puiterwijk!
After reading the PR response and looking over the bug, I think this will take a longer time to resolve. However, you can do a temporary workaround in modularity-testing-framework - copy the fedpkg config to a temp dir, modify it and then use fedpkg --config. See https://pagure.io/fedpkg/pull-request/120#request_diff to see the necessary changes. I tried it and it works.
Apr 20 2017
Fix confirmed with depcheck:
This should be now fixed everywhere:
Found it. Example: https://taskotron.fedoraproject.org/taskmaster/builders/x86_64/builds/468182
[depcheck] 20:56:06 WARNING Mirror Error: None Status code: 404 for http://infrastructure.fedoraproject.org/pub/fedora-secondary/updates/testing/24/i386/repodata/repomd.xml [libtaskotron] 20:56:06 CRITICAL Traceback (most recent call last): Exception: Librepo Error 19: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
Tim, can you point me to some of the crashes? I believed all of this was fixed.
It also affects task-modularity-testing-framework, which reports in html.
Apr 19 2017
Apr 11 2017
Mar 24 2017
Mar 23 2017
Mar 22 2017
Mar 21 2017
- fix docs
- accept both str and list of str in 'arch' parameters in directives
Production resultsdb seems to work better now, so lowering the priority. However, since we can't track how many tasks failed to post results (since we don't fail them if they do so), it's hard to guess how much uptime do we actually have. Maybe we should start failing jobs if resultsdb responds 5xx? Or retry a few times and fail eventually?
Mar 20 2017
D1164 has been pushed even to production. We now need a new libtaskotron release deployed to dev/stg/prod.
Mar 17 2017
D1165 is verified fixed in dev now. We can deploy to stg/production.
Googlebot stopped hammering us, new robots.txt work. They are present in ansible now. However, it didn't solve the problems, resultsdb (and execdb) is down again.
Mar 16 2017
Deployed to production. Thanks Lukas and Martin!
I have deployed new robots.txt: https://taskotron.fedoraproject.org/robots.txt
We should see whether it helps in a day or so (once Google refreshes that file). Btw, these are the current per-hour access numbers from Google:
So about 3300 hits per hour on overage, 55 per minute. They are performed in bursts, though (ten or twenty simultaneous requests, then a pause, then again).
Hey Adam, scenario reporting is now live in production.
Mar 15 2017
My planned changes will take longer than anticipated. I'll do a new libtaskotron build with the current changes only.
Mar 14 2017
- a minor tweak
Mar 13 2017
I discussed this with upstream Phab folks in the past. Project is not supposed to be filled out, just Repository. The field exists, but was supposed to mean something different, or something along those lines. IOW, you need to structure your notification rules in a different way (based on repositories, or subscribing to projects related to those repos might work too):
Koji has been fixed, so I assume this is no longer needed. @lbrabec, can you abandon this? Thanks.