Closed slayer321 closed 9 months ago
Hello, we are experiencing the same issue, any news on this? Thanks
@slayer321 / @jamiecwong - were either projects using dynamic config? (possible related to #95 )
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
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
fixed in 3.x
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 #112Orb version
eddiewebb/queue@1.12.0
What happened
I'm using the
until_front_of_line
inside the job as the command and passing theblock-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 hereExpected 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