Learn more about these different git repos.
Other Git URLs
Now that we allow submitting builds from stream branches, mass rebuild is either failing to build since master branch is out of sync or building very old stuff since people were not updating their master branch.
So, the idea here is, when a build is submitted to rawhide from a stream branch rebase the commit on top of the master branch so that it will be always in sync with master and mass rebuilds will work as usual.
Please let me know what you think.
cc @kevin @sgallagh
For more context, recent versions of fedpkg support reading a file called package.cfg in the root of the checkout with contents like
package.cfg
[koji] targets = master f29 f28 epel7
I use this for several packages so I can maintain them in stream branches, particularly libuv, a dependency of Node.js that has to be kept in sync with that package. However, the mass-rebuild just bumped and built an older version of libuv than we previously had in Fedora 30 because of this.
My suggestion to @mohanboddu was that we might want to include a hack where we automatically merge the current branch to Rawhide (with prejudice) so that a mass-rebuild will always be up to date.
I don't like the idea of fedpkg magically modifying git history when a build is done. It would be very confusing to the users in my opinion.
Can it be handled by the mass rebuild script? It could query Koji for latest build, which gives a commit from which it was built, and as part of the bump this could be merged to master.
master
$ koji buildinfo $(koji call --json listTagged f30 package=libuv latest=True | jq -r '.[] | .nvr') | grep Source: | cut -d# -f2 ac7268126671c90ff85733077e968ce66491f057
What do you mean by modifying git history? It would be adding a new merge commit .
Can it be handled by the mass rebuild script? It could query Koji for latest build, which gives a commit from which it was built, and as part of the bump this could be merged to master. $ koji buildinfo $(koji call --json listTagged f30 package=libuv latest=True | jq -r '.[] | .nvr') | grep Source: | cut -d# -f2 ac7268126671c90ff85733077e968ce66491f057
That's an interesting idea. It's possible that it could cause master to go backwards (or sideways) if they have diverged though. Maybe we check whether the most recent commit is present in master. If so, build the latest commit from master. If it's not present in master but is present in exactly one other branch, build the latest commit from that branch. If it's present in multiple branches, generate a list for rel-eng to send out after the mass-rebuild is done to the maintainers of packages that could not be auto-rebuilt.
WDYT?
What do you mean by modifying git history? It would be adding a new merge commit.
My bad. I meant when users submit builds, they just don't expect anything to happen to their git repo.
As for the rest, what you wrote sounds reasonable to me as well. In any case it should not be handled by fedpkg.
@mohanboddu What do you think about my proposal in https://pagure.io/fedpkg/issue/308#comment-553554 ? Should we move this to the releng mass-rebuild issue tracker instead?
Log in to comment on this ticket.