Orb not working properly for BitBucket

[jlenos]

I am trying to use this as the first step in one of my jobs.

queue/until_front_of_line:
  vcs-type: bitbucket

I triggered 2 workflows that utilized the same job.
I expected it not to continue but it still did with the following output.

queues queueable
This build will block until all previous builds complete.
Max Queue Time: 10 minutes.
Only blocking execution if running previous jobs on branch: queues
Attempting to access CircleCI api. If the build process fails after this step, ensure your CIRCLECI_API_KEY is set.
API access successful
Orb parameter block-worflow is false.
Only blocking execution if running previous jobs matching this job: build_release-1
Oldest job: 
This Workflow Timestamp: ""
Oldest Workflow Timestamp: ""
Front of the line, WooHoo!, Build continuing

The This Workflow Timestamp: "" line looked suspicious so I decided to dig into the code.
I found that when calling the API, I was seeing this for all jobs:

"all_commit_details" : [ {
    "committer_date" : "",
    "body" : "",
    "branch" : "queues",
    "author_date" : "2019-02-05T19:25:55+00:00",
    ...

Seeing that this was likely the cause, I went and copied all the code and swapped out committer_date with author_date and also tried queued_at. Both allowed this step to work as intended.
Is it possible to get a new version of this orb that utilizes author_date or queued_at in the case where committer_date is not populated?

[eddiewebb]

Thanks for the detailed write up! I'll need to confirm that the 2 suggested dates are authoritative to the ordering of commits on the repo, and if so can swap this out.

[jlenos]

@eddiewebb Any update on this issue? We would like to use this Orb as we hit failed deployments at least once a week and having this working would prevent that.

[stevenharman]

This seems odd as committer_date is from Git itself, rather than something added by GitHub/Bitbucket. Specifically, author_date is when commit was originally made But committer_date is changed when commit is modified, e.g., when rebasing the branch, applying a patch, etc...

At least, that's my understanding. Which still leaves me wondering why bitbucket isn't giving that value.

[prashcr]

From my understanding, both committer_date and author_date are from git:
https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History
https://stackoverflow.com/a/11857467

It's quite strange that committer_date is blank, but I don't think we can move further without a repro BitBucket repository/commits.
I don't think we should use author_date as it may be completely different from the committer_date. E.g. commit made 2 weeks ago on branch B was merged into branch A today.
I assume queued_at should be very similar to committer_date, with a slight delay as a commit needs to be processed by VCS and then CircleCI before it's queued.

I'll create a PR that uses queued_at if the committer_date is blank, let me know if there are any concerns.

[eddiewebb]

The new v2 API exposes means to get the date the underlying trigger was received, which should be authoritative.

This will be a2 step call to get the pipeline id of the current job, and then get pipeline details, which includes the received date of trigger.

https://eddiewebb.github.io/circleci-samples/ includes API docs.

This new endpoint also should help us eliminate race scenario by collecting status of workflows, and not individual jobs

[eddiewebb]

@kobim has contributed a fix that should address this, please anyone who can test and feedback on eddiewebb/queue@dev:37