-
Notifications
You must be signed in to change notification settings - Fork 461
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 at all, they only can be declined or revoked, so they even exists when their targets or one of their targets was deleted.
This section explains more about over database layer for requests. It only covers parts, which are not obvious.
[...]
An instance of BSRequest represents one request in OBS. When working on requests (for example: in urls), we use request numbers which are stored in the number column of every request. 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. To act on these relations, you can access the attributes target_project_object and target_package_object, as long as the source where a request comes from is not a remote project. 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
- Test in kanku
- 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
- Package Versions
- next_rails
- Ruby Update
- Rails Profiling
- 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
- Brakeman
- How to Introduce Software Design Patterns
- Query Objects
- Services
- View Components
- RFC: Core Components
- RFC: Decorator Pattern
- RFC: Backend models
- RFC: Hotwire Turbo Frames Pattern