Determine root.log vs build.log failures
by Miro Hrončok
Hey!
Koji is always very nice and it tells me whether a build failure was caused by
root.log or build.log. See for example:
https://koji.fedoraproject.org/koji/taskinfo?taskID=28963878
BuildError: error building package (arch x86_64), mock exited with status 1; see
build.log for more information
Is Copr presenting this kind of information somewhere? (I need to fetch it for
hundreds of builds.)
I could probably HTTP HEAD the build.log and check Content-Length to guess a
root.log failure, but it feels weird...
Thanks for tips.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 3 months
Attempt to build SRPM have failed:
by Miro Hrončok
I have plenty of SRPm errors like this:
Building for target x86_64
Wrote: /builddir/build/SRPMS/python-doit-0.31.1-5.fc31.src.rpm
Finish: rpmbuild -bs
INFO: chroot_scan: 3 files copied to /var/lib/copr-rpmbuild/results/chroot_scan
INFO:
/var/lib/mock/895102-fedora-rawhide-x86_64-1556487528.374044/root/var/log/dnf.rpm.log
/var/lib/mock/895102-fedora-rawhide-x86_64-1556487528.374044/root/var/log/dnf.librepo.log
/var/lib/mock/895102-fedora-rawhide-x86_64-1556487528.374044/root/var/log/dnf.log
Finish: buildsrpm
ERROR: Exception(/tmp/tmp8__qgt_0/python-doit.spec)
Config(895102-fedora-rawhide-x86_64) 1 minutes 8 seconds
INFO: Results and/or logs in: /var/lib/copr-rpmbuild/results
INFO: Cleaning up build root ('cleanup_on_failure=True')
Start: clean chroot
INFO: unmounting tmpfs.
Finish: clean chroot
Traceback (most recent call last):
File "/usr/libexec/mock/mock", line 977, in <module>
main()
File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py", line
96, in trace
result = func(*args, **kw)
File "/usr/libexec/mock/mock", line 766, in main
run_command(options, args, config_opts, commands, buildroot, state)
File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py", line
96, in trace
result = func(*args, **kw)
File "/usr/libexec/mock/mock", line 864, in run_command
do_buildsrpm(config_opts, commands, buildroot, options, args)
File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py", line
96, in trace
result = func(*args, **kw)
File "/usr/libexec/mock/mock", line 559, in do_buildsrpm
cmd=cmd, post=None, clean=clean)
File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py"
(the exception itself is probably missing from the log.)
What can it be?
See https://copr.fedorainfracloud.org/coprs/g/python/python3.8/builds/ failed
builds without package name.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 5 months
Re: Legal flag raised on rpm-gitoverlay-1556488700.270103
by Miroslav Suchý
Dne 29. 04. 19 v 0:39 root(a)copr-fe.cloud.fedoraproject.org napsal(a):
> rpmsoftwaremanagement generates dozens of empty projects.
> It doesn't seem normal, more like some bot goes crazy.
> Contact on owner is: rpmsoftwaremanagement <rpmsoftwaremanagement(a)gmail.com>
> Reported by zawertun <zawertun(a)gmail.com>
>
It is fine. They are creating new project for every pull request and as far I can see, they really build something into
those projects.
I spoke to them some time ago and I asked them to tick the "Hide from front page". They promised to do, but it will need
some time.
Miroslav
4 years, 5 months
Resubmit via CLI or Python API
by Miro Hrončok
Hey again.
I like to resubmit a failed build via command line. I didn't find this option in
copr --help or in https://python-copr.readthedocs.io
I'd like to avoid reuploading the SRPM.
In the web frontend, I just navigate to a failed build, click Resubmit -
"Resubmitting a build will rebuild the same sources again."
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 5 months
New Copr release
by Jakub Kadlcik
Hello,
I am happy to announce a new Copr release. This time we have focused mainly
on improving a CI experience and freeing up some disk space, but there is
much more. These are some highlights from this release.
- CLI support for managing permissions
------------------------------------
For quite some time, you have asked for a possibility to manage project
permissions through copr-cli or API. This is now possible, see
copr-cli request-permissions --help
copr-cli list-permissions --help
copr-cli edit-permissions --help
- Temporary projects
------------------
Many people use Copr for CI, which may include creating new projects.
Those are usually relevant for only a limited time and after that just
floods up the projects list. Instead of automatizing the deletion of
old projects all by yourself, try using temporary projects. When creating
or editing a project, it is possible to set an optional "Delete after days"
field in the Settings tab. There is also a command line option for this.
copr-cli create ... --delete-after-days <number>
copr-cli modify ... --delete-after-days <number>
- Automatic removal of old builds
-------------------------------
Another feature useful for CI, but also for normal projects. Sometimes,
you don't care about old builds and they just slow working with
builds table. Avoid this by going to package settings and specifying
the optional "Max number of builds" parameter. Alternatively, use a
command line.
copr-cli add-package-* --max-builds <number>
copr-cli edit-package-* --max-builds <number>
This keeps last <number> builds of this package. Older builds are
automatically deleted.
Note that our general policy for [builds
retention](https://docs.pagure.org/copr.copr/user_documentation.html#how-...
still applies.
- Pagure CI fixes
----------------
Copr is for quite some time listening on fedmsg to react on PR and PUSH
events from Pagure (both src.fedoraproject.org and pagure.io).
However, previously
it had several limitations;
1) only the last commit from "push" or pull-request was analyzed, and thus
only builds for packages updated by _the last_ commit were triggered, this
is now fixed and copr analyses complete push/pull-request changes,
2) only one build per pull-reqeust could ever exist, this artificial rule
was relaxed and now each PR update (new commit, rebase, ...) triggers
a new copr build,
3) the fedmsg listener stopped receiving messages after some time and
a restart was needed, workaround for this was installed (and we plan to
move to fedora-messaging which should be more reliable),
4) there was a small rhbz#1699245 bug.
As a bonus point, it is now enough to add a pull-request comment with
`[copr-build]` keyword to manually (re)trigger the CI builds.
- Saving up some disk space
-------------------------
We are struggling with low disk space and hoping to free some up
by removing backend and distgit data for old builds. To be specific
- we are now removing:
* old SRPM import logs
* old tar files from dist-git look-aside cache
* SRPM from failed builds older than 14 days
- Turning off notifications for outdated chroots removal
------------------------------------------------------
Talking of disk space, we have recently started sending
notifications about an upcoming deletion of builds for outdated
chroots. The notifications suggest that if you still care about
an outdated distribution, going to project settings and prolong
the time for which the data is going to be preserved. If you don't
care about it and don't want to be bothered by emails, you can now
instantly expire the time and schedule the chroot to be removed.
- Respecting module buildorder
----------------------------
When building a module, the `buildorder` was not respected. This
issue is now fixed.
- Private data in separate tables
-------------------------------
We have moved secret/private data about users and projects to
separate tables. This alone is not very interesting information.
However, it will allow us to dump our database (except for those
private tables of course) and share them to the public. This
will allow you to do custom data analysis and statistics.
Jakub
4 years, 5 months
