QA specific infrastructure
Pull request here: https://github.com/fedora-infra/fmn/pull/197
Tue, May 23
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
This is not valid anymore with either kararip's COPR or the packages up for review.
Until the package reviews go through, use kararip's copr. https://copr.fedorainfracloud.org/coprs/kanarip/phabricator/
Fri, May 12
Apr 24 2017
'compose' is in the canonical list of accepted types: https://pagure.io/taskotron/libtaskotron/blob/develop/f/libtaskotron/check.py#_244
I'm not exactly sure what the problem is, I didn't know we even use that item type.
Apr 21 2017
Gzipping disabled on dev for the modularity demo next week.
I can confirm this is now working. No need for modularity-testing-framework workaround anymore. Thanks, @puiterwijk!
The fedpkg config change should not be required to work anymore since I have just updated DNS so the internal IP is used for access to pkgs.fp.o, which should resolve this issue in the short term.
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.
It should be solved ideally during Monday 24th.
We will build huge set of modules during Tuesday 25th and testing would go over taskotron.
Apr 20 2017
I've submitted a PR to fix the issue:
Filed issue with fedpkg to fix the problem:
So I fixed it for html. It's not pretty but it should do for this particular use case, for now. Leaving open until I come up with a proper solution.
This will be definitely shown in the next Modularity demo. Sprint #29.
Please fix it asap. We will do hackfest Tue 25 and would be fine to fix the issue before it.
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.
We need to fix this sooner than later since this will impact dist git tasks that will have reports in html.
Apr 19 2017
As far as I know, this is done. The biggest problem is that now the non-26 builds of i686 are failing for the same reason that the 26+ builds used to fail - can't find the correct URL
Mar 21 2017
Project has been deleted
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
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
I'm updating the tasks to throw an exception if it can't get the image.
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).
I don't think that's a FAILED, honestly. If the images don't work - that's an execution error, not a test failure
I'd put this response in the task that was being called - as I thought it fit what "NEEDS_INSPECTION" was supposed to be. I've updated the task to report "FAILED" in these instances, so we'll see a failure in this case. Closing this issue.
Mar 15 2017
A short term patch could be to increase the number of processes allocated to the wsgi application.