Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

yum::copr is not always idempotent #340

Closed
jay7x opened this issue Dec 8, 2024 · 0 comments · Fixed by #341
Closed

yum::copr is not always idempotent #340

jay7x opened this issue Dec 8, 2024 · 0 comments · Fixed by #341
Labels
bug Something isn't working

Comments

@jay7x
Copy link
Member

jay7x commented Dec 8, 2024

When COPR is added by a group name (@caddy/caddy in my case), it is not idempotent.

How to reproduce (e.g Puppet code you use)

yum::copr { '@caddy/caddy': }

What are you seeing

You'll see the dnf -y copr enable @caddy/caddy executed again, because egrep in the unless case doesn't match.

Some more info related:

# ls -1 /etc/yum.repos.d/_copr*
/etc/yum.repos.d/_copr:copr.fedorainfracloud.org:copart:restic.repo
/etc/yum.repos.d/_copr:copr.fedorainfracloud.org:group_caddy:caddy.repo

# dnf copr list --enabled
copr.fedorainfracloud.org/copart/restic
copr.fedorainfracloud.org/group_caddy/caddy

So unless case here fails in this case: https://github.com/voxpupuli/puppet-yum/blob/master/manifests/copr.pp#L34.

What behaviour did you expect instead

yum::copr resource to be idempotent (do not change anything on subsequent runs).

jay7x added a commit to jay7x/puppet-yum that referenced this issue Dec 8, 2024
@bastelfreak bastelfreak added the bug Something isn't working label Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants