eddiewebb / circleci-queue

CircleCI orb to block/queue jobs to enforce max concurrency limits
MIT License
74 stars 75 forks source link

[semver:patch] Setting block-workflow as false in until_front_of_line doesn't works as expected #94

Closed slayer321 closed 9 months ago

slayer321 commented 1 year ago

RELEASE CANDIDATE READY

➡️ Potential fix for this issue is ready ⬅️

For anyone willing to validate on non-critical workloads, please use eddiewebb/queue@dev:506 and report any issues on #112


Orb version

eddiewebb/queue@1.12.0

What happened

I'm using the until_front_of_line inside the job as the command and passing the block-workflow as false (also tried removing it as it is by default false) after setting this when I created multiple commits in a short succession . Both the commits CI's runs together. You can check the Demo project where I have tested it here

Expected behavior

It should block the second commits CI until the first commit CI finishes. After checking the code here I found that is says echo "Only blocking execution if running previous jobs matching this job: ${JOB_NAME}" It seems it should block the second commit CI because both are running same Job.. but it didn't work as expected.

I have also shared the first and second commit where I have tested it first : https://github.com/slayer321/Demo_project/commit/82382fea1aa87936de378fa67b1b539163d1b2de second: https://github.com/slayer321/Demo_project/commit/3bf7e99125506e681c400d288a3268e7ad3afe4b

jamiecwong commented 1 year ago

Hello, we are experiencing the same issue, any news on this? Thanks

eddiewebb commented 1 year ago

@slayer321 / @jamiecwong - were either projects using dynamic config? (possible related to #95 )

baraschi commented 1 year ago

Hi @eddiewebb , we (with @jamiecwong ) are not using dynamic config in our orb. Only the following

  queue: eddiewebb/queue@1.8.1
  orb-tools: circleci/orb-tools@10.0
  bats: circleci/bats@1.0
  shellcheck: circleci/shellcheck@2.0
jenny-miggin commented 1 year ago

Having taken a look at some output, it seems that the Oldest job and Oldest Workflow Timestamp are not being set correctly, and I wonder if that's where the issue lies?

From my tests (using eddiewebb/queue@1.8.1 and cimg/base:2021.07-20.04, as well as the latest versions of both), the output should look something like:

Orb parameter block-workflow is false.
Only blocking execution if running previous jobs matching this job: build
Oldest job: 24
This Workflow Timestamp: "2023-04-27T12:11:43Z"
Oldest Workflow Timestamp: "2023-04-27T12:07:20Z"
This build (25) is queued, waiting for build number (24) to complete.

however output for affected users will have something like:

Oldest job: null
This Workflow Timestamp: "2023-04-27T12:11:43Z"
Oldest Workflow Timestamp: null

This points to something happening with the creation or parsing of /tmp/augmented_jobstatus.json

eddiewebb commented 9 months ago

fixed in 3.x