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.
Maxim Burgerhout
Marvin Pohl
mrstanwell
Benjamin Füldner
Benjamin Füldner
kaou