(No) Stale Tags in Koji
by Tim Flink
It looks like I was a little quick to say something in the QA meeting
this morning.
I assumed that the errors in upgradepath were due to stale tags instead
of the epoch issue that jskladan and kparal are working on. I was wrong.
So, false alarm. No stale tags to report.
Tim
13 years, 2 months
[AutoQA] #287: Create git branch for stable code and document the workflow
by fedora-badges
#287: Create git branch for stable code and document the workflow
-----------------------+----------------------------------------------------
Reporter: kparal | Owner: kparal
Type: task | Status: new
Priority: major | Milestone: Packaging, Review, & Deployment
Component: packaging | Keywords:
-----------------------+----------------------------------------------------
Currently we have our development code in master branch (kind of
'rawhide'). In the last days it became clear that we also need some
'stable' branch (kind of 'branched'). It will contain only the code
currently pushed to production or commits and hotfixes we surely want to
have included in the next revision release.
Document this workflow on the wiki.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/287>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 2 months
Re: AutoQA Comments in Bodhi
by Tim Flink
On 03/23/2011 11:19 AM, Tim Flink wrote:
> Bodhi comments were enabled earlier today in AutoQA and as some have
> noticed, old updates are being tagged as failed even though they have
> already been pushed to stable updates.
>
> We are aware of the issue and are working on it. We will send out
> another email once the issue has been resolved.
>
> Tim
The root of the problem was some stale tags in Koji (old builds with
-pending tags still on them).
AutoQA pulls in anything with *-pending tags from koji and runs tests on
them. When older packages were pulled into the upgradepath test, they
were compared against newer builds and the test would fail because you
can't "upgrade" to a previous version.
Two bugs were found in Bodhi's tag handling logic and we're hoping for
fixes in the next day or so. Once those fixes are in and we've verified
that the tests are pulling in packages correctly, we'll re-enable
AutoQA's Bodhi comments with less spam and more testing awesomeness.
To help prevent problems like this from happening in the future, the
AutoQA team is already working on a better staging/testing process
before pushing out to production. We should have that in place before
the next major release of AutoQA.
Kudos are due to lmacken, caillon and jkeating for their help in
reporting, triaging and fixing this issue.
Thanks for your patience,
Tim
13 years, 2 months
[AutoQA] #285: noarch test should be run on only one arch
by fedora-badges
#285: noarch test should be run on only one arch
--------------------+-------------------------------------------------------
Reporter: tflink | Owner:
Type: defect | Status: new
Priority: major | Milestone: 0.5.0
Component: tests | Keywords:
--------------------+-------------------------------------------------------
Currently upgradepath will test any noarch packages on both i386 and
x86_64.
This is not needed and noarch packages should be tested on one or the
other.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/285>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 2 months
[AutoQA] #288: Use proper numbering scheme
by fedora-badges
#288: Use proper numbering scheme
-----------------------+----------------------------------------------------
Reporter: kparal | Owner: jlaska
Type: task | Status: new
Priority: minor | Milestone: Packaging, Review, & Deployment
Component: packaging | Keywords:
-----------------------+----------------------------------------------------
Currently we release bug fixes by incrementing package release version.
That is probably incorrect, we should increment it only for packaging
changes:
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag
The release number (referred to in some older documentation as a
"vepoch") is how the maintainer marks build revisions, starting from 1.
When a minor change (spec file changed, patch added/removed) occurs, or a
package is rebuilt to use newer headers or libraries, the release number
should be incremented. If a major change (new version of the software
being packaged) occurs, the version number should be changed to reflect
the new software version, and the release number should be reset to 1.
Most project use this versioning scheme [1] (correct me if I'm wrong or
you have better terminology):
''major.minor.revision''
Major for large software changes, minor for smaller changes and new
features, revision for bug fixes.
The final Fedora package then looks like:
autoqa-major.minor.revision-release
This proposal is to change our versioning scheme to match the above one.
We will increment revision number for bug fixes (like hotfixing depcheck
and deploying to production) and revision increments for packaging
changes.
Ideas/concerns?
[1] http://en.wikipedia.org/wiki/Software_versioning
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/288>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
13 years, 2 months
[PATCH] cron: decrease scheduling period for koji watcher to 30 min
by Kamil Paral
This is to prevent concurrency issues (ticket #290). Once we have it
solved, we can decrease the period once again.
---
autoqa.cron | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/autoqa.cron b/autoqa.cron
index 360b5f0..25a1e94 100644
--- a/autoqa.cron
+++ b/autoqa.cron
@@ -6,5 +6,7 @@
# Run the repo watcher every 30 minutes
2,32 * * * * autotest /usr/share/autoqa/post-repo-update/watch-repos.py
-# Run the koji watcher every 10 minutes, starting at :00
-0,10,20,30,40,50 * * * * autotest /usr/share/autoqa/post-koji-build/watch-koji-builds.py
+# Run the koji watcher every 30 minutes, starting at :10
+# FIXME: Schedule koji watcher more often when concurrency issues are handled
+# (see https://fedorahosted.org/autoqa/ticket/290)
+10,40 * * * * autotest /usr/share/autoqa/post-koji-build/watch-koji-builds.py
--
1.7.4
13 years, 2 months
Re: [Fedora Update] [comment] thunderbird-3.1.8-3.fc15
by Kamil Paral
> Why did autoqa send this mail, despite that
> - This updates was already pushed into stable on 2011-03-06
> - And even there is newer updates thunderbird-3.1.9-1.fc15, which was
> already
> pushed into stable on 2011-03-13
> ?
>
> Regards,
> Mamoru
Thanks for reporting this issue. It was caused by invalid koji tags applied to that package. Detailed explanation is described in email "Re: AutoQA Comments in Bodhi" from Tim Flink, sent to autoqa-devel and devel lists. Until we resolve the issue, we will keep bodhi commenting off.
Thanks,
Kamil
13 years, 2 months
Tickets 262, 273 and 266
by Vitezslav Humpa
Hi people,
I have done some work on tickets 262, 273 and 266 - concerning change of hook architecture to watcher/event and some refactoring of the AutoQA script.
Basically, the idea was to split the hook directory and put watchers into separate directory from hooks - which'd be called events. Together with this came the need to actually completely eliminate the term "hook" from AutoQA project, which I have done partially - on the main level. "Hooks" appear pretty much everywhere, including tests, so I am waiting with complete refactoring to events until I have some feedback.
So right now: hook directory ceased to exist, autoqa script mentions hooks no longer including the help messages etc., autoqa script has been organized into functions/procedures to make more sense, makefile has been rewritten accordingly to install the new directories, autoqa.config and cron files has also been edited to reflect the new "architecture".
To my knowledge and testing, these changes in architecture made no changes/regressions to the functionality, however I need you guys to confirm, if that is true. Additionally, if you have some time, please go over the change - as this was my first thing to do with AutoQA - to check whether I didn't create some obvious trouble.
I have created a new remote branch origin/vhumpa, where the code is stored. Please checkout the origin/vhumpa an try to "make clean install" the project and run some tests as you are used to, to see, if the behavior is the same. Please also delete the "/etc/autoqa.conf" before the first install as this file doesn't get deleted during the clean (the /usr/share/autoqa also didn't used to, however the new /usr/share/autoqa/watchers and /usr/share/autoqa/events now do).
I must admit that I am so far not familiar with the usual change confirming / patching process - please, anybody let me know if there is something particular to do that I omitted.
Thank you team!
--
Vita Humpa
Red Hat Brno
13 years, 2 months
