For "woodpecker-ci" the `name` is "Woodpecker CI"
and the `login` is "woodpecker-ci"
Fixes#2092
This was causing the organization lookup to fail, because it looks up
using the `login`, when it did not find the organization, it would try
to create it. The creation would fail, because it uses the `name`, and
an organization with that `name` already exists.
Resulting in:
```
pq: duplicate key value violates unique constraint "UQE_orgs_name"
```
error logs like:
```
{"level":"warn","error":"sql: no rows in result set","time":"2023-07-25T21:29:56Z"}
```
have to less context to be helpfull.
this will cange it as the message now looks like:
```
{"level":"warn","error":"GetPipelineLast: sql: no rows in result set", "time":"2023-07-27T02:54:25+02:00"}
```
closes#1743
fixes: setting secrets for own user namespace
- create org in database
- use orgID for org related APIs
Co-authored-by: 6543 <6543@obermui.de>
In order to test this functionality, we had to expose the `BranchHead()`
through an API endpoint
```
GET /repos/{repo_id}/branches/{branch}/head
```
The response is a string that contains the latest commit hash of the
requested branch.
for now it's not clear defined, what to do on an unsupported event.
e.g. gitea webhook panel shows 500 error and no message.
now we have a successful webhook and a message to show an info
This PR introduces two new server configuration options, for providing a
custom .JS and .CSS file.
These can be used to show custom banner messages, add
environment-dependent signals, or simply a corporate logo.
### Motivation (what problem I try to solve)
I'm operating Woodpecker in multiple k8s clusters for different
environments.
When having multiple browser tabs open, I prefer strong indicators for
each environment.
E.g. a red "PROD" banner, or just a blue "QA" banner.
Also, we sometimes need to have the chance for maintenance, and instead
of broadcasting emails,
I prefer a banner message, stating something like: "Heads-up: there's a
planned downtime, next Friday, blabla...".
Also, I like to have the firm's logo visible, which makes Woodpecker
look more like an integral part of our platform.
### Implementation notes
* Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE```
and ```WOODPECKER_CUSTOM_JS_FILE```
* I've piggy-bagged the existing handler for assets, as it seemed to me
a minimally invasive approach
* the option along with an example is documented
* a simple unit test for the Gin-handler ensures some regression safety
* no extra dependencies are introduced
### Visual example
The documented example will look like this.
### Areas of uncertainty
This is my first contribution to Woodpecker and I tried my best to align
with your conventions.
That said, I found myself uncertain about these things and would be glad
about getting feedback.
* The handler tests are somewhat different than the other ones because I
wanted to keep them simple - I hope that still matches your coding
guidelines
* caching the page sometimes will let the browser not recognize changes
and a user must reload. I'm not fully into the details of how caching is
implemented and neither can judge if it's a real problem. Another pair
of eyes would be good.
Using an empty token for an agent was returning the first agent from the
database as the orm is not adding where clauses for empty strings of a
model when querying.
# Huge thanks for reporting and explaining the issue ❤️
- Dominik Heidler
- Timo Tomasini
closes#1801closes#1815closes#1144
closes #983
closes #557closes#1827
regression of #1791
# TODO
- [x] adjust log model
- [x] add migration for logs
- [x] send log line via grpc using step-id
- [x] save log-line to db
- [x] stream log-lines to UI
- [x] use less structs for log-data
- [x] make web UI work
- [x] display logs loaded from db
- [x] display streaming logs
- [ ] ~~make migration work~~ -> dedicated pull (#1828)
# TESTED
- [x] new logs are stored in database
- [x] log retrieval via cli (of new logs) works
- [x] log streaming works (tested via curl & webui)
- [x] log retrieval via web (of new logs) works
---------
Co-authored-by: 6543 <6543@obermui.de>
This isolates single migration tasks from each other.
The migration itself is now not atomic anymore but each single migration
now on it's own.
This takes load away from databases, as new sessions have a committed
schema available.
We also disable xorm.cache, as the speed improvements are minor but
invalid cache caused by schema changes did happen already in the past.
---------
Reverts #1817Closes#1821
---------
Co-authored-by: 6543 <6543@obermui.de>
