Having played with the 1.6.0 version a bit, I found that I had to change
the repository_owner and repository_name name from head_reponame and
head_owner to repository_name and owner, respectively.
Originally, I got the status reported on the source repository, on the
previous commit in my repo. What I wanted was to have the status
reported on the PR on the target repo.
I admit I haven't done a huge amount of reading of the code, but what it
looks like to me is that head_reponame and head_owner are refering to
the source repo, so I changed those to repository_name and owner, which
- at least for my setup - point to the target repository of the PR.
Furthermore, in the 1.6.0 code, sha was set to sourcestamp['revision'],
which for me points to the previous commit in the repo, meaning the
status would be reported on the wrong commit in case of a PR.
So for PRs (which I think all have 'head_sha' in props), I am setting
sha to props['head_sha'].
The result of this change for me is that the status of PR testing is
reported on the target repo on the correct commit (so showing up as
green checkmarks / yellow balls / red crosses on the PR).
For normal commits on this same repo, this also works.
I don't fully understand the impact of these API changes, but without
them the status from buildbot upon a successful build was causing gitea
to mark commits with a yellow circle instead of a green checkmark.
Since GiteaStatusPush was based on GitLabStatusPush in the first place,
I tried making it look more like its ancestor -- and now the commit status
in gitea is working correctly.
Apparently, as of buildbot 2.9.x, [reporters need to provide their own
checkConfig() implementation when a service has custom args not supplied
to the superclass](https://github.com/buildbot/buildbot/pull/5571). If
we don't do this, checkconfig will fail.
The gitea webhook list of pushed commits is in order from newest to
oldest. If commits are appended to the changes array and returned, the
last commit in the array will be the oldest commit in the push.
However, buildbot treats the last change as the *most* recent. This
means that unless you use 'alwaysUseLatest=True' in your Git step, the
Git step will not check out the newest commit in the push. If you
happen to be using 'shallow=True', this will actually cause the Git
update step to fail because only the newest commit is available in a
shallow checkout.
This update inserts each commit in the gitea webhook call at the
beginning of the array, which means buildbot sees them in chronological
order. A Git step with 'shallow=True' will now succeed.
