Skip to content

Commit 00367fd

Browse files
meakshmeaksh
committed
Initial text for new maintaining workflow for Salt
1 parent 9604c97 commit 00367fd

File tree

1 file changed

+214
-0
lines changed

1 file changed

+214
-0
lines changed

‎accepted/0000-salt-new-maintaining-workflow.md

Lines changed: 214 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,214 @@
1+
- Feature Name: An improved workflow for maintaining Salt
2+
- Start Date: 2024-11-14
3+
4+
# Summary
5+
[summary]: #summary
6+
7+
This RFC proposed an improved workflow for maintaining the Salt package for openSUSE/SUSE distributions, and therefore for Uyuni and SUSE Manager.
8+
9+
# Motivation
10+
[motivation]: #motivation
11+
12+
Our current workflow for maintaining Salt requires manual user intervention after the changes are merged into our `openSUSE/salt` codebase, in order to make this changes available in OBS. Moreover, the Salt spec file and patches are tracked in a separated GitHub repository `openSUSE/salt-packaging`, that is also used to generate the changelog entries for the final RPM.
13+
14+
All these steps needs to be performed manually, with the help of some tooling, to eventually create a manual Submit Request to our Salt package in OBS.
15+
16+
With Salt Extensions appearing now in the upcoming Salt 3008 release, we want to introduce a new workflow that suits better and solves some the limitations we currently have.
17+
18+
The purpose of this RFC is:
19+
- Define an new workflow for Salt that reduces user intervention to zero after a given PR is merged in `openSUSE/salt` repository until getting the package ready to consume at OBS.
20+
- Make the Salt maintaining workflow aligned with openSUSE practices.
21+
- Provide a workflow that can also work the same way with packaged Salt Extensions.
22+
- Deprecate the usage of `salt-packaging` repository.
23+
24+
# Detailed design
25+
[design]: #detailed-design
26+
27+
In this new workflow the `openSUSE/salt` GitHub repository will become the unique source of thrust, and it will contain:
28+
29+
- Salt codebase
30+
- Packaging artifacts: spec file, changelog and extra sources
31+
- OBS workflow file
32+
33+
Taking inspiration from the [OBS/SCM integration guide](https://openbuildservice.org/help/manuals/obs-user-guide/cha-obs-scm-ci-workflow-integration), the new workflow will use OBS workflows and GitHub Webhooks to automate pulling the changes from GitHub to OBS.
34+
35+
In addition to this, as new Jenkins job will take care of making the OBS package ready to be submitted to openSUSE or SLE.
36+
37+
This is how the proposed OBS structure would look like:
38+
39+
- `systemsmanagement:saltstack/salt`:
40+
* no services enabled - package ready to be submitted to openSUSE or SLE.
41+
* branched from `systemsmanagement:saltstack:github/salt`
42+
- `systemsmanagement:saltstack:github/salt`:
43+
* services enabled
44+
* package building based on `openSUSE/release/xxxx` GitHub branch.
45+
- `systemsmanagement:saltstack:github:CI:...:PR-XXXX/salt`:
46+
* services enabled
47+
* package building according to PR branch.
48+
* branched and removed automatically from `systemsmanagement:saltstack:github/salt` by OBS workflow.
49+
50+
### Packaging artifacts
51+
52+
All current extra "Sources" files in our RPM package, together with spec file and changelog file will go now to a `pkg/suse/` directory in `openSUSE/salt`:
53+
54+
```
55+
pkg/suse/README.SUSE
56+
pkg/suse/html.tar.bz2
57+
pkg/suse/salt-tmpfiles.d
58+
pkg/suse/transactional_update.conf
59+
pkg/suse/update-documentation.sh
60+
pkg/suse/salt.spec
61+
pkg/suse/salt.changes
62+
```
63+
64+
This is the place now where all those files will be maintained.
65+
66+
#### Salt RPM changelog
67+
68+
As mentioned this is now at `pkg/suse/salt.changes` in `openSUSE/salt` GitHub repo.
69+
70+
When creating a PR to `openSUSE/salt` the user must also include the corresponding changes to the spec file, that can be generated as usual with `osc vc`.
71+
72+
Similarly to the main Uyuni repository, we should add a GitHub action to warn the user in case no changelog entry is added in the PR.
73+
74+
### OBS project structure
75+
76+
#### `systemsmanagement:saltstack:github/salt`
77+
78+
This OBS package will only contain `_multibuild` file and a `_service` file that should look like:
79+
80+
```
81+
<services>
82+
<service name="obs_scm">
83+
<param name="url">https://github.com/openSUSE/salt.git</param>
84+
<param name="scm">git</param>
85+
<param name="versionformat">@PARENT_TAG@</param>
86+
<param name="versionrewrite-pattern">v(.*)</param>
87+
<param name="revision">openSUSE/release/xxxx</param>
88+
<param name="extract">pkg/suse/salt.*</param>
89+
</service>
90+
<service name="set_version" />
91+
<service name="tar" mode="buildtime"/>
92+
<service name="recompress" mode="buildtime">
93+
<param name="file">*.tar</param>
94+
<param name="compression">gz</param>
95+
</service>
96+
</services>
97+
```
98+
99+
#### `systemsmanagement:saltstack/salt`
100+
101+
This OBS package is a branch from `systemsmanagement:saltstack:github/salt`, where we disable the services and manually run them to get the spec file, changelog and obsinfo/obscpio files, so the package can be submitted to openSUSE or SLE.
102+
103+
The `_service` file should look like:
104+
105+
```
106+
<services>
107+
<service name="obs_scm" mode="manual">
108+
<param name="url">https://github.com/openSUSE/salt.git</param>
109+
<param name="scm">git</param>
110+
<param name="versionformat">@PARENT_TAG@</param>
111+
<param name="versionrewrite-pattern">v(.*)</param>
112+
<param name="revision">openSUSE/devel/master</param>
113+
<param name="extract">pkg/suse/salt.*</param>
114+
</service>
115+
<service name="set_version" mode="manual" />
116+
<service name="tar" mode="buildtime"/>
117+
<service name="recompress" mode="buildtime">
118+
<param name="file">*.tar</param>
119+
<param name="compression">gz</param>
120+
</service>
121+
</services>
122+
```
123+
And it should only contain the following files:
124+
125+
```
126+
_multibuild
127+
_service
128+
salt-xxxx.obscpio
129+
salt.changes
130+
salt.obsinfo
131+
salt.spec
132+
```
133+
134+
### OBS and GitHub Webhook integration
135+
136+
As described in the [SCM/CI Workflow integration guide](https://openbuildservice.org/help/manuals/obs-user-guide/cha-obs-scm-ci-workflow-integration#sec-obs-obs-scm-ci-workflow-integration-setup-token-authentication-how-to-authenticate-obs-with-scm), a "GitHub Personal Access Token" must be created and a "GitHub Webhook" configure at `openSUSE/salt` repository.
137+
138+
139+
#### OBS workflow file
140+
141+
A `.obs/workflows.yml` will be also added to `openSUSE/salt` to define the OBS workflow as the following:
142+
143+
```
144+
main_workflow:
145+
steps:
146+
- branch_package:
147+
source_project: systemsmanagement:saltstack:github
148+
source_package: salt
149+
target_project: systemsmanagement:saltstack:github:CI
150+
filters:
151+
event: pull_request
152+
153+
rebuild_master:
154+
steps:
155+
- trigger_services:
156+
project: systemsmanagement:saltstack:github
157+
package: salt
158+
filters:
159+
event: push
160+
branches:
161+
only:
162+
- openSUSE/release/xxxx
163+
```
164+
165+
This workflow will take care of:
166+
167+
- Setting up a new subproject at `systemsmanagement:saltstack:github:CI:...:PR-XXXX/salt` for every incoming PR to build the Salt package according to the changes in the PR.
168+
- Triggering the services at `systemsmanagement:saltstack:github/salt` on any new push to `openSUSE/release/xxxx` to build the package accordingly.
169+
170+
### Making OBS packages ready to submit
171+
172+
Since the package at `systemsmanagement:saltstack:github/salt` has "services" enabled, and we cannot enable/disable services using OBS workflows, this means this package is not yet ready to be submitted to openSUSE or SLE, as they don't accept enabled services on their submissions. We must disable the services.
173+
174+
In order to do this we will use an Jenkins job that monitors when a new build is done at `systemsmanagement:saltstack:github/salt` to trigger the following actions at the main `systemsmanagement:saltstack/salt` package:
175+
176+
```
177+
# osc checkout systemsmanagement:saltstack/salt
178+
# cd systemsmanagement:saltstack/salt
179+
# osc service manualrun
180+
# osc commit -m "Push new changes from GitHub"
181+
```
182+
183+
This way, we ensure `salt.spec` and `salt.changes` and obscpio/obsinfo files gets upgraded according to latest changes.
184+
185+
### Proof-of-Concept
186+
187+
I've implemented this structure and automation here:
188+
189+
- GitHub repository: https://github.com/meaksh/salt/ (`openSUSE/devel/master` branch)
190+
- OBS:
191+
* https://build.opensuse.org/package/show/home:PSuarezHernandez:tests/salt
192+
* https://build.opensuse.org/package/show/home:PSuarezHernandez:tests:github/salt
193+
* https://build.opensuse.org/package/show/home:PSuarezHernandez:tests:github:CI:....:PR-XX/salt
194+
195+
- Example PR:
196+
* https://github.com/meaksh/salt/pull/10
197+
* https://build.opensuse.org/package/show/home:PSuarezHernandez:tests:github:CI:meaksh:salt:PR-10/salt
198+
199+
Feel free to open new PRs against `openSUSE/devel/master` to see this in action.
200+
201+
# Drawbacks
202+
[drawbacks]: #drawbacks
203+
204+
TBD
205+
206+
# Alternatives
207+
[alternatives]: #alternatives
208+
209+
TDB
210+
211+
# Unresolved questions
212+
[unresolved]: #unresolved-questions
213+
214+
TBD

0 commit comments

Comments
 (0)