Push resource fabrication
I have started working on (https://gitlab.com/gitlab-org/gitlab-ee/issues/12385) and after pushing my first changes to an MR, I have seen just how far this is reaching and thus think this would be a good time (after the work on the EE coverage) to start some work on this part of the framework.
resource/repository
folder
The The problem that I have seen with this folder is that on the one side it is supposed to create the most basic unit of resource that is available on GIT
lab and that is a commit. Because of that, this idea of just adding a fabricate_via_api
to the ProjectPush is not just a simple addition. The main problem here was and is that we have until now always used the placeholder fabricate
which tries to use the API and if that does not work uses the browser_ui method. It was used everywhere even when the use of the "browser" was explicit (see push over http). This of course makes this change in ProjectPush a bit harder than just adding that function because we need to check every test that uses it.
browser_ui
for git
The usage of This would on its own not be that much of a problem. Go over all the tests that use it and see if one needs git or can use the API. Then we can see the start of some strange practises. To use git we use fabricate_via_browser_ui
... That's not right? I use git. So we have two options. Either use browser_ui for a normal git push or api for a creation of a commit over the API.
Changing to a different resource
My thinking here was that the basic premise of a push as a resource is in this case kind of wrong. The basic unit we are creating is a commit
. So the idea would be to change to a commit as a resource. The commit would not really have a browser creation except if we want to use webIDE for this way of resource creation. It would have two ways of creation: fabricate_via_api
and fabricate_via_git
. There are other things that are currently in discussion where something like fabricate_via_git seems quite logical outside of just Push (e.g. the use of git request-pull for merge request creation)
This fabricate method would use the already implemented Git class which can be found in qa/git
but it would be just a more logical way of using git through fabricate because it is just another way of creating something.
Repository::Commit.fabricate_via_git! do |commit|
commit.project = project
commit.branch = 'qa-test-branch'
commit.start_branch = 'master'
commit.file = Template.Readme
end
This example can be created also using fabricate_via_api
. As you can see there are two things a bit different than usual. The naming of the variables for branches is different because (and this is debatable) it is not that clear often what which branch is supposed to be. In Push you can find @branch_name = 'master'
but also
def remote_branch
@remote_branch ||= branch_name
end
and in MergeRequest resource one can see the usage:
resource.branch_name = target_branch
resource.remote_branch = source_branch
@source_branch = "qa-test-feature-#{SecureRandom.hex(8)}"
@target_branch = "master"
So remote_branch
is in this case the actual branch we are pushing to and branch_name
is the branch we are diverging from. This can be confusing since the API naming is much more on point here with branch
and start_branch
. For this reason my suggestion would be to use their naming convention and keep it in sync.
The second change is the Template collection of files. I would implement a files collection to be able to use template files or if there is a need for a very specific file, self defined files and push or send them over the api all at once and not just one file per commit (a .files
call).
Going over all the tests would in this case be necessary as well but we would have a logically much more correct setup that would be also much more understandable and easier to use for someone on the outside and for new TAEs as well.
This issue would be a replacement for (https://gitlab.com/gitlab-org/gitlab-ee/issues/12385)
/cc @gl-quality