git-workflow/autogits
SHA256
21
2
Fork 13
Code Issues 47 Pull Requests 13 Actions 2 Projects 2 Activity

obs-staging-bot: allow forking projects and build-disabling their repositories #111

Open
epaolantonio wants to merge 2 commits from epaolantonio/autogits:epaolantonio/pkglistgen into main
pull from: epaolantonio/autogits:epaolantonio/pkglistgen
merge into: git-workflow:main
Conversation 9 Commits 2 Files Changed 4 +74 -7
epaolantonio commented 2026-01-15 18:41:18 +01:00
Contributor
Copy Link

If enabled in the staging configuration, the git repository linked
in the Origin project used when creating the QA projects will be forked,
in a separate organization as specified in the ForkOrganization
configuration.

This allows other stakeholders (like the pkglistgen bot) to write
in there as part of the staging pipeline.

Furthermore, using the BuildDisableRepos configuration, it is now possible to
define which repositories to build-disable in the QA project meta.

This is for example useful for the SLES development workflow, where
the product repository should only be enabled after the packagelist
definitions have been built - so it is not desirable to have them
built as soon as the QA project is created.

Example configuration:

    {
      "ObsProject": "SUSE:SLFO:Main",
      "StagingProject": "SUSE:SLFO:Main:PullRequest",
      "ForkOrganization": "products-staging",
      "QA": [
        {
          "Name": "SLES",
          "Origin": "SUSE:SLFO:Products:SLES:16.1",
          "ForkProject": true,
          "BuildDisableRepos": ["product"]
        }
      ]
    }
If enabled in the staging configuration, the git repository linked in the Origin project used when creating the QA projects will be forked, in a separate organization as specified in the ForkOrganization configuration. This allows other stakeholders (like the pkglistgen bot) to write in there as part of the staging pipeline. Furthermore, using the BuildDisableRepos configuration, it is now possible to define which repositories to build-disable in the QA project meta. This is for example useful for the SLES development workflow, where the product repository should only be enabled after the packagelist definitions have been built - so it is not desirable to have them built as soon as the QA project is created. Example configuration: ``` { "ObsProject": "SUSE:SLFO:Main", "StagingProject": "SUSE:SLFO:Main:PullRequest", "ForkOrganization": "products-staging", "QA": [ { "Name": "SLES", "Origin": "SUSE:SLFO:Products:SLES:16.1", "ForkProject": true, "BuildDisableRepos": ["product"] } ] } ```
epaolantonio added 3 commits 2026-01-15 18:41:19 +01:00
common: utils: add Slugify method 12b66eb180 
Signed-off-by: Eugenio Paolantonio <eugenio.paolantonio@suse.com>
obs-staging-bot: allow forking QA projects c74f7676ba 
If enabled in the staging configuration, the git repository linked
in the Origin project used when creating the QA projects will be forked,
in a separate organization as specified in the ForkOrganization
configuration.

This allows other stakeholders (like the pkglistgen bot) to write
in there as part of the staging pipeline.

Example configuration:

{
  "ObsProject": "SUSE:SLFO:Main",
  "StagingProject": "SUSE:SLFO:Main:PullRequest",
  "ForkOrganization": "products-staging",
  "QA": [
    {
      "Name": "SLES",
      "Origin": "SUSE:SLFO:Products:SLES:16.1",
      "ForkProject": true
    }
  ]
}

ForkOrganization defaults to "products-staging".
ForkProject can be specified per-QA project, and is disabled by default.

The matching repository in the ForkOrganization (like
products-staging/SLES) must be present and writeable to the
autogits_staging_bot user.

Signed-off-by: Eugenio Paolantonio <eugenio.paolantonio@suse.com>
obs-staging-bot: allow build-disabling repositories in the QA projects
Some checks failed
go-generate-check / go-generate-check (pull_request) Has been cancelled
Details
da3fe5d3d7 
Using the BuildDisableRepos configuration, it is now possible to
define which repositories to build-disable in the QA project meta.

This is for example useful for the SLES development workflow, where
the product repository should only be enabled after the packagelist
definitions have been built - so it is not desirable to have them
built as soon as the QA project is created.

Example:

    {
      "ObsProject": "SUSE:SLFO:Main",
      "StagingProject": "SUSE:SLFO:Main:PullRequest",
      "ForkOrganization": "products-staging",
      "QA": [
        {
          "Name": "SLES",
          "Origin": "SUSE:SLFO:Products:SLES:16.1",
          "ForkProject": true,
          "BuildDisableRepos": ["product"]
        }
      ]
    }

Signed-off-by: Eugenio Paolantonio <eugenio.paolantonio@suse.com>
epaolantonio requested review from adamm 2026-01-19 14:48:26 +01:00
epaolantonio force-pushed epaolantonio/pkglistgen from da3fe5d3d7 to d73bf49eb0 2026-01-19 18:00:05 +01:00 Compare
epaolantonio commented 2026-01-19 18:00:45 +01:00
Author
Contributor
Copy Link

v2:

  • Restored common.LogDebug("Setup QA sub projects") which was dropped by mistake
  • Fixed minor typo in the ForkOrganization explanation
v2: * Restored `common.LogDebug("Setup QA sub projects")` which was dropped by mistake * Fixed minor typo in the `ForkOrganization` explanation
adamm requested changes 2026-01-20 17:39:20 +01:00
common/config.go Outdated
@@ -306,6 +308,7 @@ type StagingConfig struct {
// if set, then only use pull request numbers as unique identifiers
StagingProject string
ForkOrganization string // which organization to use when forking (def: "products")
adamm commented 2026-01-20 17:23:59 +01:00
Owner
Copy Link

Would it make sense to move this to the QAConfig instead? It's only used in QAConfig anyway and this would add some flexibility.

Would it make sense to move this to the QAConfig instead? It's only used in QAConfig anyway and this would add some flexibility.
epaolantonio commented 2026-01-21 19:14:07 +01:00
Author
Contributor
Copy Link

yes, it totally does, thanks

yes, it totally does, thanks
epaolantonio marked this conversation as resolved
common/config.go Outdated
@@ -319,6 +322,7 @@ func ParseStagingConfig(data []byte) (*StagingConfig, error) {
return nil, err
}
staging.CleanupDelay = 48
staging.ForkOrganization = "products-staging"
adamm commented 2026-01-20 17:22:41 +01:00
Owner
Copy Link

This should not be there and should come from the config, no?

This should not be there and should come from the config, no?
epaolantonio marked this conversation as resolved
obs-staging-bot/main.go Outdated
@@ -408,0 +440,4 @@
repository, err = url.Parse(forked_repo.CloneURL)
if err != nil {
panic(err)
adamm commented 2026-01-20 17:37:41 +01:00
Owner
Copy Link

there's a common.PanicOnError(err) that could replace the if { panic }

there's a `common.PanicOnError(err)` that could replace the if { panic }
epaolantonio marked this conversation as resolved
adamm commented 2026-01-20 17:44:55 +01:00
Owner
Copy Link

Also, please document the new fields in the README.md

Also, *please* document the new fields in the README.md
adamm commented 2026-01-20 17:57:42 +01:00
Owner
Copy Link

One big issue here is permissions ... the config file acted by the bot is use configurable. That means this bot should not have any permissions in OBS and not in Gitea.

So maybe this forking behaviour needs to be done differently... this is the only major issue I have adding this functionality here. As-is, the staging bot has no permissions in Gitea.

One big issue here is permissions ... the config file acted by the bot is use configurable. That means this bot should not have any permissions in OBS and not in Gitea. So maybe this forking behaviour needs to be done differently... this is the only major issue I have adding this functionality here. As-is, the staging bot has no permissions in Gitea.
epaolantonio commented 2026-01-20 18:09:33 +01:00
Author
Contributor
Copy Link

Thanks for the review! Sorry, I totally missed the README.md.

So maybe this forking behaviour needs to be done differently... this is the only major issue I have adding this functionality here. As-is, the staging bot has no permissions in Gitea.

Wouldn't having a separate project be okay in that case (with the bot being able to write there)?

Thanks for the review! Sorry, I totally missed the README.md. > So maybe this forking behaviour needs to be done differently... this is the only major issue I have adding this functionality here. As-is, the staging bot has no permissions in Gitea. Wouldn't having a separate project be okay in that case (with the bot being able to write there)?
epaolantonio commented 2026-01-20 18:10:33 +01:00
Author
Contributor
Copy Link

Ah, I see what you mean. The config file taken is the one from the source PR rather than the target branch, so that is indeed an issue. Let me think about it.

Ah, I see what you mean. The config file taken is the one from the source PR rather than the target branch, so that is indeed an issue. Let me think about it.
adrianSuSE commented 2026-01-21 08:36:20 +01:00
Member
Copy Link

Regarding the permissions your are right, but this should be handled already in all places by giving the staging bot modification permissions only in the :PullRequest master project

Regarding the permissions your are right, but this should be handled already in all places by giving the staging bot modification permissions only in the :PullRequest master project
epaolantonio commented 2026-01-21 09:46:03 +01:00
Author
Contributor
Copy Link

It is not a big deal to handle the "fork" (which is just a branch push) elsewhere, the main user of this is the pkglistgen bot that should have anyway enough permissions to write to the "staging" repo.
So if it is preferable not to handle it here, I would only keep the BuildDisableRepos feature from this PR.

It is not a big deal to handle the "fork" (which is just a branch push) elsewhere, the main user of this is the pkglistgen bot that should have anyway enough permissions to write to the "staging" repo. So if it is preferable not to handle it here, I would only keep the BuildDisableRepos feature from this PR.
epaolantonio force-pushed epaolantonio/pkglistgen from d73bf49eb0 to b442025c58 2026-01-21 19:13:34 +01:00 Compare
epaolantonio commented 2026-01-21 19:17:31 +01:00
Author
Contributor
Copy Link

v3:

  • Addressed review comments, including moving the ForkOrganization inside the per-product QA definitions
  • Added documentation

I've split the BuildDisableRepos (which is the most useful part for my usecase) in #116.

So if you prefer not having the Fork stuff here, feel free to close this PR. Thanks!

v3: * Addressed review comments, including moving the ForkOrganization inside the per-product QA definitions * Added documentation I've split the BuildDisableRepos (which is the most useful part for my usecase) in #116. So if you prefer not having the Fork stuff here, feel free to close this PR. Thanks!
Some checks failed
go-generate-check / go-generate-check (pull_request) Has been cancelled
Details
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u epaolantonio/pkglistgen:epaolantonio-epaolantonio/pkglistgen
git checkout epaolantonio-epaolantonio/pkglistgen
Sign in to join this conversation.
Reviewers
No Reviewers
adamm
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
M0ses adamm adamm_super adrianSuSE andriinikitin atartamo bigironman dancermak darix dirkmueller dmach eroca jdsn jzerebecki mstrigl oertel smithfarm
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: git-workflow/autogits#111
Delete Branch "epaolantonio/autogits:epaolantonio/pkglistgen"

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?