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>
Some configuration of Bitbucket Datacenter seems to return username as
part of the clone URL. This needs to be removed for `.netrc` to work
properly.
Closes#3443
---------
Signed-off-by: Thor Anker Kvisgård Lange <tal@netic.dk>
When receiving notification by webhook the forge tries to read
information on the latest commit when constructing the pipeline. This
requires a call to the Bitbucket API which again requires the access
token to be up-to-date.
Signed-off-by: Thor Anker Kvisgård Lange <tal@netic.dk>
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>
and create a new org once a user is created (logged in for the first
time)
closes https://github.com/woodpecker-ci/woodpecker/issues/3342
---------
Co-authored-by: Anbraten <6918444+anbraten@users.noreply.github.com>
Co-authored-by: 6543 <6543@obermui.de>
This pull-requests re-introduces the Bitbucket Server support with a
more or less complete rewrite of the forge implementation. We have a lot
of on-premises git repositories hosted in Bitbucket Server and need a CI
solution for running that and Woodpecker looks promising.
The implementation is based on external Bitbucket Server REST client
library which we are maintaining and have created in another context.
Besides the original support for Bitbucket the re-implementation also
adds support for handling Bitbucket pull-request events.
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.
Currently, backend options are parsed in the yaml parser.
This has some issues:
- backend specific code should be in the backend folders
- it is not possible to add backend options for backends added via
addons
This pull request addresses the issue https://github.com/woodpecker-ci/woodpecker/issues/3210.
Ideally, the Bitbucket API should include repository permissions when
utilizing the 'get all repositories' endpoint. However, as it currently
does not provide this information, a viable solution is to fetch all
permissions for every repository and then employ a dictionary to
associate each repository with its respective permissions.
Without implementing this fix, logging in becomes problematic for users
with access to a substantial number of repositories (300+), as the
process takes over 2 minutes to complete.
---------
Co-authored-by: Alberto Alcón <albertoalcon@bit2me.com>
