Skip to content

Automate staging workflow

Jump to bottom
Jimmy Berry edited this page Sep 14, 2017 · 10 revisions
  • converge the adi and select code
  • automate all steps of the staging workflow with the exception of human troubleshooting
  • speed up the time to accept for requests

Project

Track issues and pull requests in the github project: Automate staging workflow. The project is organized into categories rather than workflow steps that are sorted newest to oldest to provide an overview of what has been done and what remains to be done.

Example

See the gist for an example of the type of proposal that can be generated for Factory.

The command used was simply:

osc staging select --try-strategies
  • not all the requests were staged since some require bootstrapping, but a proposal is still generated
  • python3 is staged by itself via the special strategy
  • KDE Applications 16.12.2 -> 16.12.3 is staged together via the devel strategy
  • variety of remaining packages group using none strategy

If the command is run with --merge option future requests will also be merged into the appropriate stagings. The merge can be accomplished due to the information stored in staging project description about the strategy used. For example the KDE applications staging includes the following.

splitter_info:
  group: KDE:Applications
  strategy: {name: devel}

Service

After each command has been improved to the point where it can run in an automated fashion the plan is to run them all as part of a series of services. The commands in bold are currently running against Leap 42.3 and Factory.

Daily

  • ./devel-project.py reviews --min-age 4 --remind
  • ./devel-project.py requests --min-age 4 --remind
  • osc staging unignore --cleanup

Regularly (15-30 min)

  • osc staging accept
  • osc staging freeze
  • osc staging unselect --cleanup
  • osc staging repair --cleanup
  • osc staging rebuild
  • osc staging adi --by-develproject (drop flag for Factory)
  • osc staging list --supersede
  • osc staging select --non-interactive --merge --try-strategies
  • osc staging diagnose

Human intervention

Aside from diagnosing and resolving issues there may be times when a human wishes to tell the automation to leave things along. For that there are two mechanisms:

  • ignore request: Any requests that need to be postponed should be marked ignored to avoid automated commands from considering them. Use osc staging ignore -m "reason" and osc staging unselect -m "reason".
  • ignore staging: Remove the splitter_info information to avoid future merges. The tools will ignore non-empty stagings without splitter_info.
Clone this wiki locally