[opensuse-buildservice] Re: withbinaries copyproject without rebuild

13 Dec 2013

      Another issues...
Copybuild is executed for every package and scheduler schedule build on first copied package, because other packages are not copied yet.
So, i stop worker, run copy, wait while everything copied, stop scheduler, wipe build jobs, run scheduler back and it become happy.

I see that everywhere is used link(), rep_server puts binaries to job dir with link and then scheduler picks them with link().
Finally there are 6 hard links for one binary (from every :repo, :full, $packid/). 
Am i right that If i corrupt binary in src project, then all binaries will be broken in dst?

On Dec 12, 2013, at 20:37 , Kanstantsin Shautsou  wrote:
...
On Dec 12, 2013, at 20:14 , Michael Schroeder  wrote:
...
On Thu, Dec 12, 2013 at 08:02:39PM +0300, Kanstantsin Shautsou wrote:
...
On Dec 12, 2013, at 19:20 , Michael Schroeder  wrote:
...
On Thu, Dec 12, 2013 at 01:44:34PM +0300, Kanstantsin Shautsou wrote:
...
I did more debug and found :
- .mrev has duplicated entries during creation - https://github.com/openSUSE/open-build-service/issues/529
Yeah, that's a bug in the API or WEBUI.
...
- no need to increase revision when makeolder isn?t set
Why not? That really depends on your use case. As copying always
resets the "rebuild counter", we always bump the revision so that
the freshly build packages are "newer" than the old ones.
Rebuild counter will be right if i copy .rev without changes in srcserver and history+meta in repserver.
Yes, *if* you copy everything in the reposerver you can get away
with not bumping the revision. The "$packid/history" file containing
the "rebuild counter" is currently not copied, though.
In my modifications i copy and seems scheduler is fine.
...
...
...
- why you do renumbering for ?withhistory??
Because we can't have multiple revisions with the same id. If the
package did not exist before, it will get the same ids.
But this is a problem only in case when we want increase vrev (and that?s why do additional commit) that has no sense when we have makeolder that adds the second commit.
What's vrev got to do with the revisions? My point is that when the
package already exists in the target project, with have multiple
"rev=1" entries.
...
...
...
- lsrev() and addmeta() are changing hashes for SERVICE entries => it enough to just copy existed .rev with MD5SUMS files
Not in all cases. Maybe if "noservice" is given. Otherwise, all services
are re-run (or course only for the latest revision).
Even with noservices.
That's fixed with the latest commits.
...
...
...
- why do you need random generator for SERVICE entries? It can avoid new revision when nothing changed (related https://github.com/openSUSE/open-build-service/issues/278 )
Because the result does not only depend on the package content, but
also on the services configured in the project. And, maybe more important,
if the service is of the "fetch this url" type, the result may be
different files, so we need to have a different identifier for the
result.
No matter how service configured, you have resulted files from what you can do md5 and then create summary md5, so when service fetch the same files you will have the same hash. And this can avoid new MD5SUMS with the same content + avoid new revisions.
I think you're missing my point. If "noservice" is not used in the
copy, it is expected that the servic is re-run and may create a
different result.
I don’t see that services are running during copy… Or maybe they just didn’t produce new revision...
...
...
That's not true for package links, here the result only depends on
the link content, so we don't need to have to create unique ids.
...
- copying .rev without changes allow to be in sync with ?history? entries, i think it make sense to pass ?withhistory? option to rep_server so it copy ?history? and meta files?
checkin history and meta files only live on the source server, so passing
that to the repo server makes no sense.
:meta/$pack and $pack/history lives in /build/project/repo/arch/ directory so if i use withhistory+withbinaries+ no makeolder - i can have one in one copy of project.
$pack/history is the build history, not the source history. The
"withhistory" parameter is used to copy the source history.
Right, but for copyproject we have entry point in backend(==src_server), that call repserver. My idea: path withhistory to repserver (so it copy additionally meta+history) when we have withbinaries+withhistory arguments.
Then i can have one-in-one copy for withbinaries+withhistory+no make older, in other cases you can bump any revision and new hashes you want :)
...
...
I think we can have all variants of copy (including without rebuild) using existed parameters...
Yes, the "copy binaries" part is currently a bit lacking.
M.
-- 
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org