This is the first step towards support for multiple forges (#138). It
inserts a forge using the currently existing env varaibles into db and
uses this forge from db later on in all places of the code.
closes#621
addresses #138
# TODO
- [x] add forges table
- [x] add id of forge to repo
- [x] use forge of repo
- [x] add forge from env vars to db if not exists
- [x] migrate repo.ForgeID to the newly generated forge
- [x] support cache with forge from repo
- [x] maybe add forge loading cache? (use LRU cache for forges, I expect
users to have less than 10 forges normally)
---------
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
We can not just update some records for steps, as we want the pipeline
engine as single source of truth but not manage the state.
And the server should only manage the state but not how pipelines work.
We can match the pipeline but neither workflows or steps 1:1, so we
"update" them as a whole by deleting existing workflow and step data and
insert the new info from engine.
close #3494
close #3472
---------
*Sponsored by Kithara Software GmbH*
---------
Co-authored-by: Robert Kaussow <xoxys@rknet.org>
This stores workflows and steps to DB even if it is not yet approved and
thus blocked.
I'm not really happy with this, because even though it is stored, it
must parse the pipeline again and set back the original UUID. If you
have any ideas how to fix/improve this just comment.
In addition, this allows to view step list and side panel for approved
pipelines, https://github.com/woodpecker-ci/woodpecker/pull/2345 is
partially not longer necessary.
Closes https://github.com/woodpecker-ci/woodpecker/issues/895
---------
Co-authored-by: 6543 <6543@obermui.de>
Closes https://github.com/woodpecker-ci/woodpecker/discussions/2174
- return bad habit error if no event filter is set
- If this is applied, it's useless to allow `exclude`s on events.
Therefore, deprecate it together with `include`s which should be
replaced by `base.StringOrSlice` later.
Mostly those that did not require much work.
From #2960
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Because of the check `if step.Stopped == 0`
without the check there are edgecases where could be the case a stoped
steped can be markt as running again, witch is wrong.
I do remember we have "running" steps indefinetly in cancled pipelines.
This could be the fix, i just did not test that specific.
Anyway the func hat a good testcoverage ... so just look at the tests
_Source:
https://github.com/woodpecker-ci/woodpecker/pull/3143#discussion_r1446138088_
https://go.dev/doc/modules/release-workflow#breaking
Fixes https://github.com/woodpecker-ci/woodpecker/issues/2913 fixes
#2654
```
runephilosof@fedora:~/code/platform-woodpecker/woodpecker-repo-configurator (master)$ go get go.woodpecker-ci.org/woodpecker@v2.0.0
go: go.woodpecker-ci.org/woodpecker@v2.0.0: invalid version: module contains a go.mod file, so module path must match major version ("go.woodpecker-ci.org/woodpecker/v2")
```
---------
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
- refactor pipeline parsing
- do not parse the pipeline multiple times to perform filter checks, do
this once and perform checks on the result directly
- code deduplication
- refactor forge token refreshing
- move refreshing to a helper func to reduce code
---------
Co-authored-by: Anbraten <anton@ju60.de>
