Currently, all API handler functions take care of response code and
message on their own. This leads to a huge injection chain for HTTP
related objects.
This refactors the API to consistently return response code and message
to the API main entrypoint where the response is created and sent.
Now, SonarQube and Gitea will get a response at the very end of any bot
action for one request. SonarQube has a timeout of 10 seconds, which may
be reached due to network latency. We'll see.
Signed-off-by: Steven Kriegler <sk.bunsenbrenner@gmail.com>
With PR #17 the Helm Chart parameters for webhook secrets were missing
in the README parameters. This is now fixed.
A checksum for bot configuration secret resource ensures replacement of
the pod when there is a configuration change.
Additional:
- Bump Chart default image version
- Add bug fix notes to changelog
Signed-off-by: Steven Kriegler <sk.bunsenbrenner@gmail.com>
Due to unhandled errors within the SonarQube client, users may be
presented with Go panics or just don't know what the root cause of a
non-working bot is.
Now it is possible to identify network errors, authentication issues or
an incorrect bot configuration regarding SonarQube.
Fixes: #20
Signed-off-by: Steven Kriegler <sk.bunsenbrenner@gmail.com>
This introduces a new application option `--port`/`-p` to switch the
listening port from 3000 (default) to another port.
Docker image can be configured using the corresponding environment
variable `GITEA_SQ_BOT_PORT`.
Helm Chart allows setting `.Values.app.listeningPort`
Resolves: #25
Signed-off-by: Steven Kriegler <sk.bunsenbrenner@gmail.com>
Instead of re-inventing the wheel regarding configuration location
handling and validation, this introduces a new command flag `--config`
allowing for full flexibility of configuration filename and location.
This flag can also be defined via environment variable which allows
an easy way of starting the bot from command line, inside a Docker
container or using the Helm Chart.
It makes the custom environment lookup unnecessary and reduces some
complexity during startup and for writing tests.
Resolves: #10
Signed-off-by: Steven Kriegler <sk.bunsenbrenner@gmail.com>
The current code base regarding API entrypoint is not testable as it
directly connects to Gitea when creating the API endpoints. This
prevented my from writing tests in the past for that part.
As the SonarQube quality gate broke due to changes in the API entrypoint
logic, tests are now required to satisfy the quality gate.
Therefore, the instantiation of the API handlers is now decoupled from
building the bot API endpoints and follows the same interface wrapper
strategy as used for the Gitea API client. This makes it testable.
Now, tests are written for the most parts of the API entrypoint. I've
also noticed that there was much overhead within the tests for a
non-implemented function `fetchDetails`. So I dropped that function for
now.
Signed-off-by: Steven Kriegler <sk.bunsenbrenner@gmail.com>
Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com>
Reviewed-on: https://codeberg.org/justusbunsi/gitea-sonarqube-bot/pulls/22
- Auto-generate parameters documentation
- Provide required `make` commands
- Update contribution environment to match new requirements
Signed-off-by: Steven Kriegler <sk.bunsenbrenner@gmail.com>
