waiting for suitable set of input version/ discovering any new versions

[ashmeet72]

i setup pipeline locally & running on docker image but most of time when i triggered job then pipeline
go into state of waiting for suitable set of input version/ discovering any new versions infinite. i look on google for many things
but not got resolution.below is screen shot.can anyone help me with this.

[jamieklassen]

can you provide the complete pipeline yaml you are using?

[ashmeet72]

resources:
  - name: resource-tutorial1
    type: git
    source:
      username: yarn###
      password: yarn77777
      uri: https://github.com/yarn/dob.git
      branch: master


  - name: resource-tutorial2
    type: git
    source:
      username: yarn###
      password: yarn77777
      uri: https://github.com/yarn/dob.git
      branch: master

jobs:
  - name: hello_world_job1
    plan:
      - get: resource-tutorial1
        trigger: true
      - task: tester
        config:
          platform: linux
          image_resource:
            type: docker-image
            source: { repository: ubuntu }
          run:
            path: echo
            args: ["Hello, world!"]
        
  - name: hello_world_job2
    plan:
      - get: resource-tutorial1
        passed: [hello_world_job1]
      - task: tester
        config:
          platform: linux
          image_resource:
            type: docker-image
            source: { repository: ubuntu }
          run:
            path: echo
            args: ["Hello, worlds!"]

  - name: hello_world_job3
    serial: true
    plan:
      - get: resource-tutorial2
      - get: resource-tutorial1
        passed: [hello_world_job1]
        passed: [hello_world_job2]
      - task: tester
        config:
          platform: linux
          image_resource:
            type: docker-image
            source: { repository: ubuntu }
          run:
            path: echo
            args: ["Hello, worlds!"]

[jamieklassen]

It sounds like you were expecting to be able to trigger hello_world_job3 and have it run before hello_world_job2 had completed. Is that correct?

[jamieklassen]

the most common reason I can remember that happening on v5 is when the resource fails to check

[jamieklassen]

sometimes running fly check-resource has gotten clusters in that state unstuck

[jamieklassen]

do you want hello_world_job3 to only run when hello_world_job1 and hello_world_job2 have passed? while we're at it... what are these jobs actually for? you mention mysterious "restrictions" but the jobs you shared seem to be toys that don't do anything so I'm assuming you have anonymized them. Maybe knowing a bit more about the use case would be helpful.

[ashmeet72]

i want hello_world_job3 to run when hello_world_job2 job is green or passed.

[jamieklassen]

'passed constraint' doesn't mean 'run whenever another job is currently green'. It refers to individual versions. What I'm struggling with here is that you say

i want to trigger hello_world_job3 without triggering hello_world_job2

and yet at the same time

i want hello_world_job3 to run when hello_world_job2 job is green or passed.

and these sound mutually exclusive. The only commits that job3 will run on will be commits that job2 has already succeeded on. Is that much fair to say?

[jamieklassen]

I haven't been able to reproduce this on Concourse v5 or v6 with any of the configurations you have described - my cluster never gets stuck 'checking for latest available versions', so I think we might need to know a bit more about what else is going on in your cluster.

1. Are you deploying with docker-compose? can you share your docker-compose.yml?
2. What other pipelines are running on the same instance? In your screenshot I see main-pipeline, main-pipeline1 and hello-world. Can you share configs for all of those?

[ashmeet72]

changed docker-compose.yml but many times got waiting for suitable set of inputs infinite.
below my docker-compose.yml

version: '3'

services:
concourse-db:
image: postgres
environment:
POSTGRES_DB: concourse
POSTGRES_PASSWORD: concourse_pass
POSTGRES_USER: concourse_user
PGDATA: /database

concourse:
image: concourse/concourse
command: quickstart
privileged: true
depends_on: [concourse-db]
ports: ["8080:8080"]
environment:
CONCOURSE_POSTGRES_HOST: concourse-db
CONCOURSE_POSTGRES_USER: concourse_user
CONCOURSE_POSTGRES_PASSWORD: concourse_pass
CONCOURSE_POSTGRES_DATABASE: concourse
CONCOURSE_EXTERNAL_URL: http://localhost:8080
CONCOURSE_ADD_LOCAL_USER: test:test
CONCOURSE_MAIN_TEAM_LOCAL_USER: test
CONCOURSE_WORKER_BAGGAGECLAIM_DRIVER: overlay
CONCOURSE_CLIENT_SECRET: Y29uY291cnNlLXdlYg=
CONCOURSE_TSA_CLIENT_SECRET: Y29uY291cnNlLXdvcmtlcg=

[ashmeet72]

how can i check whether cluster got stuck can you share steps to check that?
or steps i can do to check to those frequent conditions for this type errors.?