zarplata / concourse-git-bitbucket-pr-resource Goto Github PK

My test pass but when the on_success of the job tries to put back to the resource it just fails. There is not error output.

Here is my resource code

 name: pullrequest
    type: git-bitbucket-pr
    source:
      base_url: https://bitbucket.org
      bitbucket_type: cloud
      dir: pullrequest
      git:
        password: <redacted>
        uri: https://bitbucket.org/corvesta/helloworld.service
        username: cv-devops
      password: <redacted>
      project: corvesta
      repository: helloworld.service
      username: cv-devops

I've been researching use of this resource as opposed to concourse/git-resource and one of the features that appears to not be supported is the path configuration for filtering on specific changeset directories.

Given this is an extension on top of git-resource, is this config expected to work?

Hey,
I was playing around with this resource and had some issues in the beginning, because it says the docker image can be found under: concourse-git-bitbucket-pr
But this image does not exist, it should be concourse-git-bitbucket-pr-resource :)

And it should be base_url instead of url in the documentation

And I cannot use this resource when there is a whitespace in my password

Thank you for this great resource - I've been using it for a bunch of projects. To that end, I've hit the pain point of having to update my bitbucket password in multiple pipelines when I'm forced to periodically change my bitbucket password at work. To avoid this issue, I was wondering if there's a way to auth with a private key (similar to the official git resource) or personal access token instead of requiring the username/password? That would make password changes a lot easier to manage. Thanks!

Hello,

this line breaks the resource:

https://github.com/zarplata/concourse-git-bitbucket-pr-resource/blob/master/assets/check#L79

We had a PR with quotes in it (title: This is a "test"). The resource then errors on that line because it is not properly escaped

In case of there are 2 active PRs, trigger-job starts on a build for a PR that has been built last.
Is there a way to re-trigger a build of a different PR without pushing bogus commits or update PR description?

Hi there,
it seems like the paths parameter is not working. At least not the way I expect it to work (same as in the git-resource.

The resource works as intended as long as I do not add the paths parameter. I always end up getting the following error in Concourse:

Here is the current resource config (I replaced repo, project and user data):

resources:
- name: bitbucket-pull-requests
  type: git-bitbucket-pr
  source:
    base_url: https://my.base.url
    username: myusername
    password: mypassword
    project: projectA
    repository: repoA
    git:
      uri: ssh://[email protected]/projectA/repoA.git
      private_key: mysuperprivaterepokey
    paths:
      - path/to/directory

I tried changing the values in paths, no luck. In addition, I tried adding the pahts parameter within the git config. It then does not throw an error anymore, but does not filter out any paths either.

The only idea I could come up with is that in line 74 of the check file the uri is constructed differently than in line 43.
In the working one (line 43) the path is …/repos/${repository}${1}…. in line 74 it is …/repos/${repository}/….

Can anyone help to solve the problem?

System: Concourse v5.8.0, Bitbucket Server v4.5.2

Thanks in advance!

Hi! Thanks for the resource, it's very useful!

I'm wondering if it would be possible to use OAuth credentials, like other similar resources that deal with bitbucket, such as https://github.com/SHyx0rmZ/bitbucket-build-status-resource ?
Would you be interested in a PR with OAuth implemented?

• created=1637670734
  ++ curl -sSL -u sXXXXXXXXXX4:NEXXXXXXXXXXXXXXXXX https://api.bitbucket.org/2.0/repositories/aarp_appdev/cq/commit/8cc05016c7b5
• commit_details='{"data": {"shas": ["8cc05016c7b5"]}, "type": "error", "error": {"message": "Commit not found", "data": {"shas": ["8cc05016c7b5"]}}}'
  ++ echo -E '{"data": {"shas": ["8cc05016c7b5"]}, "type": "error", "error": {"message": "Commit not found", "data": {"shas": ["8cc05016c7b5"]}}}'
  ++ jq -r '.date | sub("(?.*)+-"; "(.time)Z") | fromdate // ""'
  jq: error (at :1): null (null) cannot be matched, as it is not a string
• date=

For a private repository on Bitbucket Cloud (https://bitbucket.org), the resource returning

stderr:
curl: (22) The requested URL returned error: 404 

My resource looks like this.

      base_url: https://bitbucket.org
      username: my-user-name
      password: my-password
      project: project-name
      repository: repo-name
      bitbucket_type: cloud
      git:
        uri: https://[email protected]/teamname/reponame.git
        private_key: <>

The example are not so clear in the README, what I am missing or making mistake?

Hi,
as you did commits recently, I assume you are actively using this resource. However it does not work with Bitbucket Cloud and so I conclude you are using this with a self-hosted Bitbucket server ?

I'm about to fix it up for Bitbucket Cloud. Would do a PR then if you like ?

Best !

I'm trying to use the resource to update the PR status, but I'm getting this error:

cat: can't open '/tmp/build/put/project/.git/pr': No such file or directory

This is my configuration:

• put: source-code-pr
  params:
  action: change-build-status
  state: INPROGRESS
  name: "pr-build"

Any clue on what I'm doing wrong?
I've tried several versions of the resource with same (or similar) results.
Resource works perfect for getting new PRs so I'd like to use to update them as well

I noticed that whenever I updated the description on a PR it would kick off another Concourse build because the concourse-git-bitbucket-pr-resource considered the PR to have been "updated". This is not desired behavior since there is no code change involved.

I have a fix for this and will open a PR in a moment -- just wanted to track the behavior with an issue.

Hi!

Your git tagging seems out of place. Somehow almost all your version tags point to the latest source. Hence, almost all your 'versioned' releases and also your image builds on docker hub are the same. You might wanna check this...

Concourse CI Version

v3.14.1

Configuration

anchors:
  - &ci-callback-url
    url: https://<REDACTED>/teams/$BUILD_TEAM_NAME/pipelines/$BUILD_PIPELINE_NAME/jobs/$BUILD_JOB_NAME/builds/$BUILD_NAME

  - &pullrequest-hook-params
      name: ci test
      <<: *ci-callback-url

  - &ci-failure
    on_failure:
      put: pull-requests
      params:
        <<: *pullrequest-hook-params
        state: FAILED
        description: "Failed"

Debug Output

{"key": "ci test-16063", "description": "Failed", "repository": {"links": {"self": {"href": "https://bitbucket.org/!api/2.0/repositories/<REDACTED>/<REDACTED>"}, "html": {"href": "https://bitbucket.org/<REDACTED>/<REDACTED>"}, "avatar": {"href": "https://bytebucket.org/ravatar/%<REDACTED>%7D?ts=js"}}, "type": "repository", "name": "<REDACTED>", "full_name": "<REDACTED>/<REDACTED>", "uuid": "{<REDACTED>}"}, "url": "https://<REDACTED>/teams/<REDACTED>/pipelines/<REDACTED>/jobs/ci/builds/1", "links": {"commit": {"href": "https://bitbucket.org/!api/2.0/repositories/<REDACTED>/<REDACTED>/commit/<REDACTED>"}, "self": {"href": "https://bitbucket.org/!api/2.0/repositories/<REDACTED>/<REDACTED>/commit/<REDACTED>/statuses/build/ci%20test-16063"}}, "refname": null, "state": "FAILED", "created_on": "2018-08-16T19:00:14.306608+00:00", "commit": {"hash": "<REDACTED>", "type": "commit", "links": {"self": {"href": "https://bitbucket.org/!api/2.0/repositories/<REDACTED>/<REDACTED>/commit/<REDACTED>"}, "html": {"href": "https://bitbucket.org/<REDACTED>/<REDACTED>/commits/<REDACTED>"}}}, "updated_on": "2018-08-16T19:12:25.310277+00:00", "type": "build", "name": "ci test"}

Expected Behavior

After a failed CI build, if the user clicks the '+' button to trigger a new build of the same CI job and the job passes, the Bitbucket PR should show the build as passing.

Actual Behavior

After a failed CI build, if the user clicks the '+' button to trigger a new build of the same CI job and the job passes, the Bitbucket PR shows two builds on the PR--one passing build and one failing build. If the user has the merge check Check the last commit for N successful build and no failed builds enabled, the user will be unable to merge the PR until a new commit is pushed.

Steps to Reproduce

1. Create a repository in Bitbucket Cloud.
2. Create a branch permission on the default branch and set the merge check for Check the last commit for 1 successful build and no failed builds.
3. Create a CI job in Concourse with the concourse-git-bitbucket-pr-resource configured to post back to the PR on_failure (see sample config above).
4. Configure the CI job to fail by default.
5. Create a new branch from the default branch.
6. Commit a change to the new branch.
7. Submit a PR to the default branch.
8. Observe the failed build result.
9. Fix the CI job to succeed.
10. Re-run the CI job via the build trigger in the Concourse CI web console (or via CLI).
11. Observe that two builds are posted back to the PR and that the user is unable to merge the PR.

Important Factoids

The current behavior when re-running a failed build on a PR in Bitbucket Pipelines is to set the key on the build status to the same key as the previous build thereby updating the same build status. This PR updates this resource to behave in a similar manner as the Bitbucket Pipelines product.

References

• https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D/commit/%7Bnode%7D/statuses/build
• https://concourse-ci.org/implementing-resources.html

We tried using the resource with Bitbucket cloud and noticed that the paths source config doesn't work. We have a repository with all our docker images and I wanted to validate PR per image so created multiple resource with the paths to only work on the correct images and all my resources trigger whenever a PR is created for any paths.

I took a look at the check script and yes the paths is only used with Bitbucket server.

When I read about the branch option, I thought it would allow me to specify to only listen to PRs created against a specific target branch but when I started testing I noticed that this option only works to specify a source branch.

As an example, if I have a branch feature/x and I create a PR feature/x --> develop. If I specify develop in the branch option, it never picks up the PR. If I specify feature/x, it does pick it up.

Not sure if this is intended functionality. If it is, could a target_branch be added as well?

The readme mentions that All params and source configuration of the original git-resource will be respected. However, when I try to pass ignore-paths to the resource, builds are still triggered for changes only in those paths. Is there a way to not build on certain files being changed? My repos are on bitbucket server. Here's what I thought would work:

  - name: somename
    type: git-bitbucket-pr
    source:
      base_url: somebaseurl
      username: ((user))
      password: ((pass))
      project: proj
      repository: somename
      git:
        uri: someurl.git
        private_key: ((source-git-ssh-key))
      bitbucket_type: server
      ignore-paths:
        - '**/*.md'
        - .gitignore

The equivalent with the official git resource does work:

  - name: somename
    type: git
    source:
      uri: someurl.git
      branch: master
      tag_filter: v*
      private_key: ((source-git-ssh-key))
      ignore-paths:
        - '**/*.md'
        - .gitignore

Thank you!

Here you want to change to the directory with the name of the var "repository" but it should change to the output container name, which in your example is "my-repo-with-pull-requests".

Builds are running twice again, since commit e409aeb I believe because the second build has an updated_at attribute added, not present in the first one, that difference triggers a new build.

Re-raise this as a new issue since the comments on the closed one are not getting any attention.

From @peikk0:

It's still happening, we are still seeing a updated_at attribute added in the new duplicated version, can you revert 03f87b0 too? That might actually be the one causing it instead of the other commit, or maybe both.

I need to trigger a job when a PR is raised against a branch. For example say I create a feature branch feat/xxx and I raise a PR from feat/xxx to master I need this job to run because a PR targeted master.

What I have observed is that the source.branch works the other way around, so if I set source.branch: feat/xxx it would trigger whenever I create a PR from feat/xxx regardless of the target branch.

This seems backwards to my way of thinking, is this by design or a mistake? Is there a way to achieve the behaviour I want via configuration?

Given a job like

- name: test-pull-requests
  plan:
  - get: pull-request
    trigger: true
    version: every
  - get: node
  - put: pull-request
    params:
      state: INPROGRESS
      key: concourse-build
      description: Building on Concourse
  - task: test
    image: node
    privileged: true
    file: pull-request/config/concourse/tasks/test-pull-request.yml
    timeout: 1h
    on_success:
      put: pull-request
      params:
        state: SUCCESSFUL
        key: concourse-build
        description: Ready to merge
    on_failure:
      put: pull-request
      params:
        state: FAILED
        key: concourse-build
        description: Cannot merge

INPROGRESS put causes a new version of the same PR to be created in the resourse, so Concourse builds the same commit twice.
Is there a way to configure the plugin to ignore such type of PR updates?

Ran into an issue after finally turning on build gating where older PRs were not being rebuilt in concourse.

This appears to be caused by the check function only returning the most recent PR for the Cloud configuration.
Submitted a PR #54 which removes that functionality, which should correctly update all available metadata and allow for concourse to correctly rebuild older PRs with updates.

Hi,

we're using this resource in our project but it seems that recently the url field (also used in your example configuration for the on_success / on_failure step) does not seem to be used anymore - it always points to the concourse resource.