Store StagingWorkflow in the backend

[DavidKang]

StagingWorkflow is stored in the backend under _project directory with
the name _staging_workflow. In this special file, we store a minimal
info of the staging_workflow.

[adrianschroeter]

You should also implement the read and update from the file to the database in the same commit/pull request if you use a source file here. Otherwise data can run out of sync easily.

[coolo]

writing to that file outside of the model should be plainly forbidden IMO.

[coolo]

how about?

diff --git a/src/api/config/routes.rb b/src/api/config/routes.rb
index bb4204d7f..a49cc73c0 100644
--- a/src/api/config/routes.rb
+++ b/src/api/config/routes.rb
@@ -768,6 +768,7 @@ OBSApi::Application.routes.draw do
 
     get 'source/:project/:package/:filename' => :get_file, constraints: cons, defaults: { format: 'xml' }
     delete 'source/:project/:package/:filename' => :delete_file, constraints: cons
+    put 'source/:project/_project/_staging_workflow' => :just_dont, constraints: cons
     put 'source/:project/:package/:filename' => :update_file, constraints: cons

[adrianschroeter]

That would be just one out of many ways to work on it. And why should it be forbidden, if you add it here it is obvious that it is also the API to create/modify it, no?

[coolo]

But it's not. Creating a staging project requires more than adding it to a xml file.

[coolo]

So possibly the _staging_workflow shouldn't be a file in _project after all - where else to store it to make it obvious that it can't be edited at free will?

[hennevogel]

This is how we forbid other underscore files. An API for creating/changing this is not what we are going to do now.

[adrianschroeter]

@hennevogel this is on package name level and not on file level.

The api it needs also be writeable anyway in the end, it is bad idea to add cruel hacks to workaround some situations (and for sure not all). It shows that the design should have been documented first before hacking ....

[coolo]

does if @file == '_attribute' ring any bells, @adrianschroeter ?

[coolo]

using a file to create staging projects is a bad API anyway. So let's talk about an API to modify staging workflows independent of _project

[adrianschroeter]

_attribute is a very special case, because it can not be bind to the package model container of "_project" (since it is project model). reading works different there anyway. But this not true for a regular source file.

dunno if a file in _project makes sense for this, but it must be configurable via api anyway and there should not be two ways for same content. So, yes, better define first how to create/modify/delete it via api first before defining the place.

[hennevogel]

So let's talk about an API to modify staging workflows independent of _project

We will do that for sure, I don't like having UI or API only features either. But not now, in a later iteration.

[adrianschroeter]

@hennevogel fine if you don't want to do it now, but then don't store this file either now. It only cries for problems, stuff will be out of sync, people may use it already because they can see it....

I was only against to it partly and creating all these problems.

[hennevogel]

but then don't store this file either now

We can also just "forbid" writing to this file like we do for _attribute for now.

[DavidKang]

@hennevogel and @bgeuken could you review it again?

[hennevogel]

code* and hakiri hang. Coverage is fine, see coveralls and there are no security warnings on hakiri for this commit. Merging...