Re: Proposal: Migrating More Git Projects to Pagure
On Tue, Jan 17, 2017 at 4:40 AM, Tim Flink wrote: > The following projects have been moved to pagure.io: > > https://pagure.io/taskotron/libtaskotron > https://pagure.io/taskotron/resultsdb > https://pagure.io/taskotron/resultsdb_api > https://pagure.io/taskotron/resultsdb_frontend > https://pagure.io/taskotron/execdb > https://pagure.io/taskotron/taskotron-trigger > > https://pagure.io/fedora-qa/blockerbugs > > I have not deleted the bitbucket repos yet but I have removed write > access for pretty much everyone so that there are no accidental pushes. > Please look over the repos to see if I missed anything. Once we're sure > everything is there, we can delete the bitbucket projects or just > replace them with READMEs that point to the new pagure repos. > > Do we leave task repos on bitbucket? I am fine with it, just asking if that's intentional. > Also, I'm wondering whether we want to have a separate namespace/group > for resultsdb. I'm fine with it the way it is but figured that I would > ask to see what other folks thought. > Either way works for me, I don't have any strong preferences. Thanks for moving the repos, Tim! M. > > Tim > > On Mon, 9 Jan 2017 09:21:16 -0700 Tim Flink wrote: > > > This came up in the qadevel meeting today and I wanted to put a bit > > more detail out. > > > > Bitbucket was never intended to be the long-term home for our git > > projects - I think we're about the only folks in Fedora using it and > > it's not free software. As fedorahosted is closed down, we need to > > find a new home for blockerbugs but I figure that now is as good of a > > time as any to get all of our git projects in the same place. > > > > I'm proposing the following moves: > > > > * Move all Taskotron projects to pagure.io using the taskotron group: > >- pagure.io/taskotron/libtaskotron > >- pagure.io/taskotron/resultsdb > >- etc. > > > > * Move blockerbugs under the existing fedora-qa namespace in pagure: > >- pagure.io/fedora-qa/blockerbugs > > > > I'm not sure if there are any plans for the openqa stuff that > > currently lives on bitbucket but it'd be nice to see that moved as > > well. > > > > Any objections, comments, concerns? > > > > Tim > > > > > ___ > qa-devel mailing list -- qa-devel@lists.fedoraproject.org > To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org > > ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Re: Proposal: Migrating More Git Projects to Pagure
The following projects have been moved to pagure.io: https://pagure.io/taskotron/libtaskotron https://pagure.io/taskotron/resultsdb https://pagure.io/taskotron/resultsdb_api https://pagure.io/taskotron/resultsdb_frontend https://pagure.io/taskotron/execdb https://pagure.io/taskotron/taskotron-trigger https://pagure.io/fedora-qa/blockerbugs I have not deleted the bitbucket repos yet but I have removed write access for pretty much everyone so that there are no accidental pushes. Please look over the repos to see if I missed anything. Once we're sure everything is there, we can delete the bitbucket projects or just replace them with READMEs that point to the new pagure repos. Also, I'm wondering whether we want to have a separate namespace/group for resultsdb. I'm fine with it the way it is but figured that I would ask to see what other folks thought. Tim On Mon, 9 Jan 2017 09:21:16 -0700 Tim Flink wrote: > This came up in the qadevel meeting today and I wanted to put a bit > more detail out. > > Bitbucket was never intended to be the long-term home for our git > projects - I think we're about the only folks in Fedora using it and > it's not free software. As fedorahosted is closed down, we need to > find a new home for blockerbugs but I figure that now is as good of a > time as any to get all of our git projects in the same place. > > I'm proposing the following moves: > > * Move all Taskotron projects to pagure.io using the taskotron group: >- pagure.io/taskotron/libtaskotron >- pagure.io/taskotron/resultsdb >- etc. > > * Move blockerbugs under the existing fedora-qa namespace in pagure: >- pagure.io/fedora-qa/blockerbugs > > I'm not sure if there are any plans for the openqa stuff that > currently lives on bitbucket but it'd be nice to see that moved as > well. > > Any objections, comments, concerns? > > Tim > pgpg0Ye1Yrlvu.pgp Description: OpenPGP digital signature ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Planned Outage: Taskotron - 2017-01-17 20:00 UTC
There will be an outage starting at 2017-01-17 20:00 UTC, which will last approximately 12 hours. To convert UTC to your local time, take a look at https://fedoraproject.org/wiki/UTCHowto or run: date -d '2016-01-17 20:00 UTC' Reason for outage: We will be upgrading Taskotron to a new version which requires a migration that will take 8-12 hours. This migration will be very infrequent if it ever happens and we don't anticipate needing long outages like this in the future All jobs which would have run during the outage will be queued for execution after the outage has completed Affected Services: All services on taskotron.fedoraproject.org Ticket Information: https://pagure.io/fedora-infrastructure/issue/5697 Contact Information: infrastruct...@lists.fedoraproject.org Please join #fedora-admin in irc.freenode.net or add comments to the ticket for this outage above. pgpG841e_KMCE.pgp Description: OpenPGP digital signature ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
2017-01-16 Fedora QA Devel Meeting Minutes
= #fedora-meeting-1: fedora-qadevel = Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2017-01-16/fedora-qadevel.2017-01-16-15.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2017-01-16/fedora-qadevel.2017-01-16-15.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2017-01-16/fedora-qadevel.2017-01-16-15.00.log.html Meeting summary --- * Roll Call (tflink, 15:00:56) * Announcements and Information (tflink, 15:04:05) * taskotron stg rebuild complete - tflink, mkrizek (tflink, 15:04:14) * libtaskotron 0.4.18 released and deployed to dev and stg - mkrizek (tflink, 15:04:14) * fix for taskotron-trigger CLI posted for review - mkrizek (tflink, 15:04:14) * LINK: https://phab.qa.fedoraproject.org/D1081 (tflink, 15:04:14) * started working on the dashboards - lbrabec, jskladan (jskladan, 15:05:47) * Rebuilding Taskotron Production (tflink, 15:07:44) * AGREED: for taskotron production redeployment, schedule a long outage for resultsdb migration and try to minimize disruption. this is a once-in-a-long-while migration and isn't worth spending days to make it faster (tflink, 15:40:20) * Task Dashboards (tflink, 15:41:53) * LINK: https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org/message/CV2W5Q5VOTZTZSMLQPG5IYMU3MMUBZGG/ (tflink, 15:42:00) * tasking (tflink, 15:49:41) * LINK: https://phab.qa.fedoraproject.org/D1012 (tflink, 15:52:25) * Open Floor (tflink, 15:56:11) Meeting ended at 15:59:22 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * tflink (86) * jskladan (40) * kparal (26) * zodbot (6) * mkrizek (5) * garretraziel (2) * linuxmodder (2) * roshi (1) * robyduck (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot pgpYvYkN9phDj.pgp Description: OpenPGP digital signature ___ qa-devel mailing list -- qa-devel@lists.fedoraproject.org To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
Re: Task Result Dashboards
On Fri, 13 Jan 2017 13:58:25 +0100 Josef Skladanka wrote: > On Thu, Jan 12, 2017 at 7:42 AM, Tim Flink wrote: > > > The idea was to start with static site generation because it doesn't > > require an application server, is easy to host and likely easier to > > develop, at least initially. > > > > I don't really have a strong preference either way, just wanted to > > say > that "initial development" time is the same for web app, and for > static generated pages - it both does the same thing - takes an input > + output template and produces output. You can't really get around > that from what I'm seeing here. Static generated page equals cached > data in the app, and for the starters we can go on using just the > stupidest of caches provided in Flask (even though it might well be > cool and interesting to use some document store later on, but that's > premature optimization now). Honestly, I don't care a whole lot about how the dashboards are implemented so long as they get done and they get done relatively quickly. > > >After brief discussion with jskladan, I understand that > > > resultsDB would be able to handle requests from dynamic page. > > > > Sure but then someone would have to write and maintain it. The > > things that drove me towards static site generation are: > > > > Write and maintain what? I'm being sarcastic here, but this sounds > like the code for static generated pages will not have to be written > and maintained... And once again - the actual code that does the > actual thing will be the same, regardless of whether the output is a > web page, or a http response. I was thinking that a static site generator would work around the need for auth and interface code to create new dashboards. We could just have a git repo with yaml files and if someone wanted a new dashboard, they could just submit a PR with the new yaml file. > > > > > * I'm not sure what exactly is meant by 'item tag' in the examples > > > section. > > > > > > * Would the YAML configuration look something like this: > > > > > >url: link.to.resultsdbapi.org > > >overview: > > >- testplan: > > > - name: LAMP > > > - items: > > >- mariadb > > >- httpd > > > - tasks: > > >- and: > > > - rpmlint > > > - depcheck > > > - or: > > >- foo > > >- bar > > > > I was thinking more of the example yaml that's in the git repo at > > taskdash/mockups/yamlspec.yml [1] but I'm not really tied to it > > strongly > > - so long as it works and the format is easy enough to understand. > > > > > I guess I know where you were going with that example, but it is a bit > lacking. For one all it really allows for is "hard and" relationship > between the testcases in the testplan (dashboard, call it whatever you > like), which might be enough, but with what was said here it will > start being insufficient pretty fast. The other thing is, that we > really want to be able to do the "item selection" in some way. We > sure could say "take all results for all these four testcases, and > produce a line-per-item" but that is so broad, that it IMO stops > making sense anywhere beyond the "global" (read applicable to all the > items in the resutsdb) testplans. This is meant as an initial direction, not a final resting place. I fully expect that the functionality will continue to evolve if we adopt the project. > > >Is there going to be any additional grouping (for example, > > > based on arch) or some kind of more precise outcome aggregation > > > (only warn if part of testplan is failing, etc.) > > > > Maybe but I think those features can be added later. Are you of the > > mind that we need to take those things into account now? > > > > > I don't really think that they can. Take a simple "gating" dashboard > for example. There is a pretty huge difference between "package > passes, if rpmlint, depcheck and abicheck pass on it" and "package > passses if rpmlint, depcheck and abicheck pass for all the required > arches". And I'm certain we want to be able to do the latter. Like it > is not really "pass" when rpmlint passed on ARM, depcheck on X86_64 > and abicheck on i386, but all the other combinations failed. Why can't all that be hardcoded for now, at least? The required checks and arches don't change very often. > It might seem like unnecessarily overcomplicating things, but I don't > thin that the dashboard-generating tool should make assumptions (like > that grouping by arch is what you want to do) - it should be spelled > out in the input format, so there is as much black box removed as > possible. Will it take more time to write the input? Sure. Is it > worth it? Absolutely. Again, this wasn't intended as a final spec but as a starting point. If at all possible, I want to have something which can be shown off as at least a demo before devconf. With that in mind, I'd like to keep everything as simple as possible for now. >
