Infrastructure/ansible
5
0
Fork 0
Code Issues Pull requests 3 Projects Releases Packages Wiki Activity Actions

Playbooks to improve the EPEL minor branching process #2593

Open
dherrera wants to merge 5 commits from epel-minor-branching into main
pull from: epel-minor-branching
merge into: Infrastructure:main
Conversation 9 Commits 5 Files changed 3 +476
dherrera commented 2025-04-29 01:24:39 +00:00
Contributor
Copy link

As it was described on this issue https://pagure.io/releng/issue/12668, one of the weak points of the current EPEL branching process is that it depends on scripts that need to run on the infrastructure with high privileges. Moving these processes into Ansible playbooks would help make it easier to delegate this part of the process using RBAC.

These playbooks serve both that purpose and would also replace the scripts located on https://pagure.io/releng/blob/main/f/scripts/branching-EPEL.

On this first PR, there are 3 playbook files:

branch-distgit-packages.yml

This playbook executes the steps described on this part of the SOP

koji-release-tags.yml

This playbook executes the steps described on this part of the SOP, that takes care of creating new Koji tags

prepare-bodhi-repos.yml

This playbook executes part of the process described on this part of the SOP, that takes care of preparing the infrastructure for a new bodhi

I'll mark this PR as a draft for now, but feel free to comment on it.

As it was described on this issue https://pagure.io/releng/issue/12668, one of the weak points of the current EPEL branching process is that it depends on scripts that need to run on the infrastructure with high privileges. Moving these processes into Ansible playbooks would help make it easier to delegate this part of the process using RBAC. These playbooks serve both that purpose and would also replace the scripts located on https://pagure.io/releng/blob/main/f/scripts/branching-EPEL. On this first PR, there are 3 playbook files: ### branch-distgit-packages.yml This playbook executes the steps described on this part of the SOP * https://docs.fedoraproject.org/en-US/infra/release_guide/sop_epel_minor_mass_branching/#_dist_git It also relieves the need of the following scripts in the process * https://pagure.io/releng/blob/main/f/scripts/branching-epel/get_all_active_packages_branching.sh * https://pagure.io/fedora-infra/ansible/blob/main/f/roles/distgit/files/mass-branching-git.py ### koji-release-tags.yml This playbook executes the steps described on this part of the SOP, that takes care of creating new Koji tags * https://docs.fedoraproject.org/en-US/infra/release_guide/sop_epel_minor_mass_branching/#_koji It also relieves the need of the following scripts in the process * https://pagure.io/releng/blob/main/f/scripts/branching-epel/make-koji-release-tags ### prepare-bodhi-repos.yml This playbook executes part of the process described on this part of the SOP, that takes care of preparing the infrastructure for a new bodhi * https://docs.fedoraproject.org/en-US/infra/release_guide/sop_epel_minor_mass_branching/#_bodhi_2 It also relieves the need of the following scripts in the process * https://pagure.io/releng/blob/main/f/scripts/branching-epel/create_empty_repos.sh --- I'll mark this PR as a draft for now, but feel free to comment on it.
zuul commented 2025-04-29 01:28:19 +00:00
First-time contributor
Copy link

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/39f145188f134c309aa94b2bb8cd1448

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci https://fedora.softwarefactory-project.io/zuul/buildset/39f145188f134c309aa94b2bb8cd1448 - [fi-ansible-lint-diff ](https://fedora.softwarefactory-project.io/zuul/build/65de66dffe094ad8b726b7f1aa598182) : FAILURE in 3m 18s - [fi-yamllint-diff ](https://fedora.softwarefactory-project.io/zuul/build/dae44e7fce8f4715ae47bd9b2c6c2a81) : FAILURE in 2m 27s
dherrera commented 2025-04-29 21:23:14 +00:00
Author
Contributor
Copy link

2 new commits added

  • Fix ansible-linter issues
  • Fix yamllint issues
**2 new commits added** * ``Fix ansible-linter issues`` * ``Fix yamllint issues``
zuul commented 2025-04-29 21:26:45 +00:00
First-time contributor
Copy link

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/f37e147483c2414b8a8fe29ca7450062

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci https://fedora.softwarefactory-project.io/zuul/buildset/f37e147483c2414b8a8fe29ca7450062 - [fi-ansible-lint-diff ](https://fedora.softwarefactory-project.io/zuul/build/95528c9b92794550bda6f1ebc11371e1) : FAILURE in 3m 00s - [fi-yamllint-diff ](https://fedora.softwarefactory-project.io/zuul/build/7b152a776a5a48c1997113fa90b6894d) : SUCCESS in 2m 33s
zuul commented 2025-04-30 18:51:26 +00:00
First-time contributor
Copy link

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/ef29c5e20a78461ab1dcf1a7b4f2ea38

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci https://fedora.softwarefactory-project.io/zuul/buildset/ef29c5e20a78461ab1dcf1a7b4f2ea38 - [fi-ansible-lint-diff ](https://fedora.softwarefactory-project.io/zuul/build/a68dbac0517b4b5ebd9dd67cd62dfc34) : FAILURE in 3m 19s - [fi-yamllint-diff ](https://fedora.softwarefactory-project.io/zuul/build/2ff114c6701f4eae98f76ba122852df1) : SUCCESS in 2m 20s
carlwgeorge commented 2025-05-02 06:05:17 +00:00
Contributor
Copy link

The current logic here will cause problems when we try to run this for 11.0. This is also a problem with the make-koji-release-tags script, but ideally we can work up some logic here that works in the dot zero scenario.

The current logic here will cause problems when we try to run this for 11.0. This is also a problem with the make-koji-release-tags script, but ideally we can work up some logic here that works in the dot zero scenario.
carlwgeorge commented 2025-05-02 20:35:23 +00:00
Contributor
Copy link

An idea occurred to me related to the .0 problem. What if we used separate playbooks for:

  • creating the next minor version
  • converting the current minor version to snapshot external repos
  • converting the current minor version to RHEL external repos

That would make it easier to just run the first playbook for the .0 releases. In that playbook the only thing that would need to reference the previous minor version is the clone-tag command, which I guess would become an add-tag command for .0.

An idea occurred to me related to the .0 problem. What if we used separate playbooks for: - creating the next minor version - converting the current minor version to snapshot external repos - converting the current minor version to RHEL external repos That would make it easier to just run the first playbook for the .0 releases. In that playbook the only thing that would need to reference the previous minor version is the clone-tag command, which I guess would become an add-tag command for .0.
dherrera commented 2025-05-06 06:31:57 +00:00
Author
Contributor
Copy link

The current logic here will cause problems when we try to run this for 11.0. This is also a problem with the make-koji-release-tags script, but ideally we can work up some logic here that works in the dot zero scenario.

There is no need to handle the zero case ^^. This playbook (like the script it was based of) is meant to be used just for the minor branching case, and the first branching is the .1 one, considering the zero one already exists when creating the major release (11.0 would be the case).

Even if there would be a problem, nothing would end up happening, because the minor value gets checked here so it's above 0 to even continue https://pagure.io/fedora-infra/ansible/pull-request/2593#_2__37

I do agree that the major release process is something we have to deal with at some point in the future though :)

> The current logic here will cause problems when we try to run this for 11.0. This is also a problem with the make-koji-release-tags script, but ideally we can work up some logic here that works in the dot zero scenario. There is no need to handle the zero case ^^. This playbook (like the script [it was based of](https://pagure.io/releng/blob/main/f/scripts/branching-epel/make-koji-release-tags)) is meant to be used just for the minor branching case, and the first branching is the .1 one, considering the zero one already exists when creating the major release (11.0 would be the case). Even if there would be a problem, nothing would end up happening, because the minor value gets checked here so it's above 0 to even continue https://pagure.io/fedora-infra/ansible/pull-request/2593#_2__37 I do agree that the major release process is something we have to deal with at some point in the future though :)
dherrera commented 2025-05-06 18:47:10 +00:00
Author
Contributor
Copy link

An idea occurred to me related to the .0 problem. What if we used separate playbooks for:

  • creating the next minor version
  • converting the current minor version to snapshot external repos
  • converting the current minor version to RHEL external repos

That would make it easier to just run the first playbook for the .0 releases. In that playbook the only thing that would need to reference the previous minor version is the clone-tag command, which I guess would become an add-tag command for .0.

I like this idea :O! I think we can iterate further on this ^^

> An idea occurred to me related to the .0 problem. What if we used separate playbooks for: > > - creating the next minor version > - converting the current minor version to snapshot external repos > - converting the current minor version to RHEL external repos > > That would make it easier to just run the first playbook for the .0 releases. In that playbook the only thing that would need to reference the previous minor version is the clone-tag command, which I guess would become an add-tag command for .0. I like this idea :O! I think we can iterate further on this ^^
zuul commented 2025-05-12 14:58:04 +00:00
First-time contributor
Copy link

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/4e3e715d68d04441a4c945bc5db07c9e

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci https://fedora.softwarefactory-project.io/zuul/buildset/4e3e715d68d04441a4c945bc5db07c9e - [fi-ansible-lint-diff ](https://fedora.softwarefactory-project.io/zuul/build/637ebaa5d16d4c56b9f23fac23cab97c) : FAILURE in 2m 56s - [fi-yamllint-diff ](https://fedora.softwarefactory-project.io/zuul/build/84ecf3edbe2648f78118f7679153dab0) : SUCCESS in 3m 00s
This pull request is broken due to missing fork information.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin epel-minor-branching:epel-minor-branching
git checkout epel-minor-branching

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git checkout main
git merge --no-ff epel-minor-branching
git checkout epel-minor-branching
git rebase main
git checkout main
git merge --ff-only epel-minor-branching
git checkout epel-minor-branching
git rebase main
git checkout main
git merge --no-ff epel-minor-branching
git checkout main
git merge --squash epel-minor-branching
git checkout main
git merge --ff-only epel-minor-branching
git checkout main
git merge epel-minor-branching
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
freeze-break-request

   
post-freeze
No labels
freeze-break-request
post-freeze
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Infrastructure/ansible#2593
No description provided.
Delete branch "epel-minor-branching"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?