-
Notifications
You must be signed in to change notification settings - Fork 441
BS Requests
Requests are always at least against one local project. It's not possible to have a remote project as target, but the source can be a remote package.
Requests cannot get deleted, they only can be declined
or revoked
and superseded, so they even exist when their targets or sources were deleted.
This section explains more about our database layer for requests. It only covers parts, which are not obvious at a first glance.
Requests always have a relation to the target project (as far as it doesn't get deleted) via the target_project_id
attribute. The target_package_id
attribute is only set, if a package exists in the target project with the name of target_package
.
Since requests never get deleted (even if their sources/targets get deleted), it's necessary to store the source project and package, and the target project and package names in a separate column.
An instance of BSRequest
represents one request in OBS. In addition to the id
attribute that any model has, the BsRequest class has a number
attribute, which is the actual identifier for requests in OBS. For example, when you go to /request/show/1
, your request will be routed to the request with its number
attribute being 1, not its id. Read more here.
A request can have multiple actions (BsRequestAction). An action defines what will happen, when the request gets accepted. Every action is described in it's own sub-class. For example, if a request has a BsRequestAction of the type (string) submit
, it will perform the code in BsRequestActionSubmit
.
An action must have a project and can have a package as a target (depending on the action type). The foreign keys for the target project and package are stored in target_project_id
and target_package_id
. You can access the relations target_project_object
and target_package_object
to act on them. Remote projects are always string and don't have an object.
Things you should be aware of:
When the target project gets deleted:
When the target package gets deleted, the request gets declined and the target_project_object
is nil
. If you still want to find out the target project name, you can access the attribute target_project
which holds the name as a string. Note that the foreign keys (pointing to the target project and package) will not get set to nil
!
This also applies to the package. If the project was deleted, the package also no longer exists.
When the target package gets deleted:
When the target package gets deleted, the request gets declined and the target_package_object
is nil
. If you still want to find out the target package name, you can access the attribute target_package
which holds the name as a string. Note that the foreign keys pointing to the target package, will not get set to nil
!
When the target_package_id is nil (for submit requests only):
It means that there is no target package with the name specified in target_package
. When accepting this request, a new package will be created.
NOTE: The class BsRequestActionAcceptInfo
is not an action itself. If a request was accepted, a new record of type BsRequestActionAcceptInfo
is being created and it holds information about the accepted request.
Mappings:
Type | Representative Class | Action |
---|---|---|
submit | BsRequestActionSubmit | changes source code or creates a new package |
delete | BsRequestActionDelete | deletes a project/package |
change_devel | BsRequestActionChangeDevel | changes the origin devel project of a project |
add_role | BsRequestActionAddRole | adds a role (e.g. the submitter wants to be a project/package maintainer) |
set_bugowner | BsRequestActionSetBugowner | sets the bugowner for a package |
maintenance_incident | BsRequestActionMaintenanceIncident | usually comes from devel projects from the maintainer of a package in order to update a package in the distribution update channels. |
maintenance_release | BsRequestActionMaintenanceRelease | a maintenance release request is created from a Maintenance Incident Project and is supposed to be released in the codestream and a set of products |
group | BsRequestActionGroup | - no longer being used - |
This model holds always only one record in which it stores the number for the next request which will be created. When a new request gets created, the counter
column gets increased by +1
. This is required for a database setup with multiple servers where it can happen that there a gaps between the incrementing id
's. To avoid those gaps, we increment the bs_request_counter.counter
table column.
The BsRequestPermissionCheck
model is being used for permission checks before a submit request can get accepted or a request state can be changed.
- Development Environment Overview
- Development Environment Tips & Tricks
- Spec-Tips
- Code Style
- Rubocop
- Testing with VCR
- Authentication
- Authorization
- Autocomplete
- BS Requests
- Events
- ProjectLog
- Notifications
- Feature Toggles
- Build Results
- Attrib classes
- Flags
- The BackendPackage Cache
- Maintenance classes
- Cloud uploader
- Delayed Jobs
- Staging Workflow
- StatusHistory
- OBS API
- Owner Search
- Search
- Links
- Distributions
- Repository
- Data Migrations
- next_rails
- Ruby Update
- Rails Profiling
- Installing a local LDAP-server
- Remote Pairing Setup Guide
- Factory Dashboard
- osc
- Setup an OBS Development Environment on macOS
- Run OpenQA smoketest locally
- Responsive Guidelines
- Importing database dumps
- Problem Statement & Solution
- Kickoff New Stuff
- New Swagger API doc
- Documentation and Communication
- GitHub Actions
- How to Introduce Software Design Patterns
- Query Objects
- Services
- View Components
- RFC: Core Components
- RFC: Decorator Pattern
- RFC: Backend models