Bug 981347

Summary: tito release fails with a traceback
Product: [Fedora] Fedora Reporter: Tomas Lestach <tlestach>
Component: titoAssignee: Devan Goodwin <dgoodwin>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 19CC: admiller, cperry, dgoodwin, dgoodwin, mmraka, tkasparek
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-09 14:59:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tomas Lestach 2013-07-04 13:58:47 UTC
Description of problem:
tito fails to build a package in koji. It looks like tito modules aren't consistent.

Version-Release number of selected component (if applicable):
tito-0.4.12-1.fc19.noarch

How reproducible:
always

Steps to Reproduce:
1. # cd spacewalk-java
2. # tito release --all

Actual results:
$ tito release --all
Will release to the following targets: koji
Checking for tag [spacewalk-java-1.10.114-1] in git repo [ssh://git.fedorahosted.org/git/spacewalk.git/]
Releasing to target: koji
Working in: /tmp/tito/release-spacewalk-java-c40e0a61774a5978b8efbda7a82266bd9f18c350wUTvAQ
Building release in Koji...
Traceback (most recent call last):
  File "/usr/bin/tito", line 23, in <module>
    CLI().main(sys.argv[1:])
  File "/usr/lib/python2.7/site-packages/tito/cli.py", line 94, in main
    return module.main(argv)
  File "/usr/lib/python2.7/site-packages/tito/cli.py", line 638, in main
    scratch=self.options.scratch)
  File "/usr/lib/python2.7/site-packages/tito/release.py", line 988, in release
    self._koji_release()
  File "/usr/lib/python2.7/site-packages/tito/release.py", line 1077, in _koji_release
    KojiReleaser._koji_release(self)
  File "/usr/lib/python2.7/site-packages/tito/release.py", line 1040, in _koji_release
    self._submit_build("koji", koji_opts, koji_tag, builder.srpm_location)
TypeError: _submit_build() takes exactly 4 arguments (5 given)


Expected results:
Triggering a build process in koji.

Additional info:
As Spacewalk project relies on tito, it's important to have tito working.

Comment 1 Tomas Lestach 2013-07-09 08:01:24 UTC
Well, I would appreciate to state the tito version, that contains the fix.
As the BZ was closed with NEXTRELEASE yesterday, I took the latest tito build from fedora koji - tito-0.4.15-1.fc19 (actually built yesterday) and I'm getting the same error as reported:

$ tito release --all
Will release to the following targets: koji
Checking for tag [spacewalk-java-1.10.124-1] in git repo [ssh://git.fedorahosted.org/git/spacewalk.git/]
Releasing to target: koji
Working in: /tmp/tito/release-spacewalk-java-ebb5520422f7a24d34eb4a5f04b8ec6fd954833byRrpLm
Building release in Koji...
Traceback (most recent call last):
  File "/usr/bin/tito", line 23, in <module>
    CLI().main(sys.argv[1:])
  File "/usr/lib/python2.7/site-packages/tito/cli.py", line 94, in main
    return module.main(argv)
  File "/usr/lib/python2.7/site-packages/tito/cli.py", line 639, in main
    scratch=self.options.scratch)
  File "/usr/lib/python2.7/site-packages/tito/release.py", line 997, in release
    self._koji_release()
  File "/usr/lib/python2.7/site-packages/tito/release.py", line 1086, in _koji_release
    KojiReleaser._koji_release(self)
  File "/usr/lib/python2.7/site-packages/tito/release.py", line 1049, in _koji_release
    self._submit_build("koji", koji_opts, koji_tag, builder.srpm_location)
TypeError: _submit_build() takes exactly 4 arguments (5 given)

$ rpm -q tito
tito-0.4.15-1.fc19.noarch


Shall I reopen the BZ? In what tito version could I expect the fix?

Comment 2 Devan Goodwin 2013-07-09 13:27:09 UTC
Koji releaser broke after 0.4.12 which looked very much like this and was fixed in 0.4.13. However I am guessing you are actually using KojiGitReleaser?

There are portions of tito that are used by no one but Satellite, this is one of them. It would be an *extremely* good idea if someone from Satellite would stay in touch with tito master to make sure Satellite's use cases stay functional in the face of contributions coming in from several other teams. 

If you or someone on satellite were to git clone https://github.com/dgoodwin/tito.git, and periodically do a "tito build --rpm --test -i" on tito itself it would be very useful for keeping Satellite working before rpms go out. I will add you to my list of people to email before release as well to test rpms before they hit stable.

Also in the future if you could please file bugs on github it would be appreciated. 

I have attempted a fix, I am not sure if the release will succeed entirely because there's no way for me to actually test it. If you could please test tito master out and let me know if everything is ok, I will tag a new build and submit to Fedora today.

Comment 3 Tomas Lestach 2013-07-09 14:15:33 UTC
Yes, we're using tito.release.KojiGitReleaser.

If you have a set of tests, that have to pass before making a new tito release, we would be happy to write one to make sure new changes do not break Spacewalk setup.

I am not really sure about filling BZs on github. In case I use tito from fedora or at least tito downloaded from http://koji.fedoraproject.org, I mean bugzilla.redhat.com is the right place for filling bugs. In case I'd use tito built from tito.git master or any other build provided by https://github.com/dgoodwin/tito.git, I'd definitely file a bug against upstream on github. Does it make sense?

As I already confirmed over IRC, tito built from current master works as expected. Thanks for fixing the issue. Information for the others: tito-0.4.16-1 shall fix the described issue.

Comment 4 Devan Goodwin 2013-07-09 14:59:48 UTC
There is a set of tests runnable with "nosetests" in test/. The tests do not currently have any coverage for releasers, as this is quite difficult to automate as we can't be submitting builds. It would be possible though, particularly for koji based builders as --dry-run will skip the actual koji commands, so no setup is required and nothing will be sent to the server. I will try to get some coverage added there today.

I ask that you file on github to help lighten the load, the tools are better, this is what all other teams are doing, and there are other people involved looking at issues and submitting pull requests so it's easier to track, and you will get better / quicker responses. If you are unable or unwilling to do this that is fine, continue to file here.