.copr: Cleanups #1812
.copr: Cleanups #1812
Conversation
martinpitt
force-pushed
the
copr-cleanups
branch
from
3845400
to
73672fb
Compare
|
Ah, checkout@v2 is also deprecated, see the warnings in current runs. Added another commit. |
.copr/make-srpm.sh
Outdated
| rpm -q rpm-build git-core || dnf install -y rpm-build git-core | ||
| rpm -q rpm-build git-core |
There was a problem hiding this comment.
Nack. The .copr scripts are primarily intended for use with COPR's "make srpm" method, where the script is expected to install its dependencies. It is reused for GitHub CI because it fits that use case as well and it means less duplicate code.
There was a problem hiding this comment.
Ah, ok -- I was going to throw it out as the next step anyway, when moving the whole build-rpms workflow and copr handling to packit (I talked to @zpytela about it yesterday). See martinpitt#1 . I'm happy to revert this, it's not important at all.
There was a problem hiding this comment.
While I'm at it, do you have a copr where you do builds from the "rawhide" branch, i.e. from landed commits? I'm happy to add that to the packit config, too.
There was a problem hiding this comment.
Not a copr, but scratchbuilds are available at Checks -> Artifacts -> rpms.zip - is that what you meant?
There was a problem hiding this comment.
I'd prefer to keep .copr/ in the repo. I use it when I have a branch with some testing changes in a branch on my fork - having the .copr directory there allows me to set up automatic COPR builds without needing to add any special changes. I would like this to be preserved along with the Packit support. I guess the make-srpm.sh script will need to be massaged a bit to be usable for both, but hopefully it won't be too complicated.
There is also https://copr.fedorainfracloud.org/coprs/omos/selinux-policy-latest that is set to build the latest rawhide branch content after every push, but I think no one actually uses it (and I presume it would be made obsolete by the Packit support).
There was a problem hiding this comment.
Packit COPRs also "just work" -- I forked the project and sent martinpitt#1 (to my own fork, as it's building on top of this), and if you follow the "rpm-build*" test contexts, you get to https://dashboard.packit.dev/results/copr-builds/912150 -- i.e. that just effortlessly works on forks as well, which is great for experiments and collaboration. That said, I can rework this to work in both cases, maybe with splitting up the script.
Your omos/selinux-policy-latest copr, you said "is set to" -- does copr itself provide automatic builds? If so, that will continue to work of course (I wasn't aware that COPR can do that). Otherwise we can add a copr on-commit job to do that, provided that you allow the "packit" user as a builder in your copr.
There was a problem hiding this comment.
Not a copr, but scratchbuilds are available at Checks -> Artifacts -> rpms.zip - is that what you meant?
@zpytela : No, that would be builds from the proposed branches, not after the merge to the main branch ("rawhide" or whichever the target is). I meant the kind of COPR that @WOnder93 mentioned above.
There was a problem hiding this comment.
Note that this discussion isn't really relevant for this PR, but very much so for the next one that I'm going to send after this lands 😁 so thanks!
There was a problem hiding this comment.
FTR: I understand that you are cautious here. I'll rework the "packit copr" PR to keep .copr/ functional as-is, and instead provide an option for make-srpm.sh to skip the rpm-build step.
Also rename it from `$dirname` to `$rootdir`, as that's too confusing with the `dirname` command.
This catches a missing $1 argument early, instead of failing the `cp` command at the very end.
As a user this isn't necessary, and potentially dangerous when running this as root. This is a workaround which is specific to running containers in GitHub workflows, so configure git there.
v2 has been deprecated for a long time, and is throwing warnings.
martinpitt
force-pushed
the
copr-cleanups
branch
from
73672fb
to
dc580fb
Compare
|
@zpytela Any chance that this can be landed? This PR should be quite harmless. Thanks! |
|
Merging now, thank you. |
While looking at moving to packit srpm/rpm builds, I came across a few cleanups which should be done to the current build script.