queue_up_workflow and wait_for_workflow not working about orbs

[roopakv]

@maciejb oh yeah i got it mxied up. we use a service account (not a big fan, bit that was the only work around I could find)

[sijangurung]

+1

[roopakv]

@sijangurung @teocomi I use this in our pipelines and a few other folks do too. So I am not sure exactly why it si failing. do you have any logs or repro steps I can look at

[sijangurung]

Can you please show us a little more detailed config.yml where you have implemented queue_up_workflow. Thanks in advance
@roopakv

[roopakv]

@sijangurung i can't post the whole workflow but I will post a snapshot.

workflows:
  production:
        jobs:
            - swissknife/queue_up_workflow:
                max-wait-time: "1800"
                workflow-name: ^(staging|production)$
            - test-something:
                context: some-secrets
                name: Some tests
            - test-something2:
                name: something2 tests
            - test-after-queue:
                name: Tests that need to be queued
                requires:
                    - swissknife/queue_up_workflow

here all test-after-queue runs will be queued.

[sijangurung]

My usecase is workflow2 should wait for workflow1 and workflow3 should wait for workflow2

workflows:
     workflow1:
           ...
           jobs:
             - common jobs
             - some conditions 
    workflow2:
           ...
           jobs: 
                - swissknife/queue_up_workflow:
                             workflow-name: "workflow1"
               - some other job               
    workflow3:
           ...
           jobs: 
                - swissknife/queue_up_workflow:
                             workflow-name: "workflow2"

This won't work @roopakv

[roopakv]

@sijangurung seems like you have some bugs i the above, but it should work. You need a requires for all jobs that depend on the queue. i.e. some-other-job needs a requires

workflows:
     workflow1:
           ...
           jobs:
             - common jobs
             - some conditions 
    workflow2:
           ...
           jobs: 
                - swissknife/queue_up_workflow:
                             workflow-name: "workflow1"
               - some-other-job:
                    requires:
                    - swissknife/queue_up_workflow              
    workflow3:
           ...
           jobs: 
                - swissknife/queue_up_workflow:
                             workflow-name: "workflow2"
                - some-job:
                     requires: 
                       - swissknife/queue_up_workflow

[sijangurung]

I tried with the code snippets you suggested, but got
Exited with code exit status 22 CircleCI received exit code 22

I am running Private bitbucket with CircleCI in an organization. Probably that has something to do .

Also, I see in your code , it has
slug="github/${CIRCLE_PROJECT_USERNAME}/$CIRCLE_PROJECT_REPONAME"

should it be VCS independent, also use $CIRCLE_VCS_NAME

[roopakv]

@sijangurung that is probably it. I have never tried nor tested outside of github. let me look up the documentation and update.

Would you be able to post the entire logs from the swissknife job if they are not sensitive? If they are sensitive could you mail them to hi[@]swissknife.dev

[maciejb]

I was also getting the same cryptic Exit 22, and was able to resolve it. If no other workflow was running, Swissknife worked happily, but as soon as there was another workflow it would fail with this message and no other clues.
The error was coming from curl step in get_workflow_start_time(), which is using the v2 api unlike the other steps using v1.1. Why this matters? My CIRCLE_TOKEN was a Project Token, not a Personal Token. According to the docs:

Currently, Personal API tokens are the only supported tokens on API v2. Project tokens are not currently supported on API v2.

Curl was returning 22 because the v2 API lookup fails.

As there is no way to query workflows on the v1.1 API, I don't think a solution is available other than to document this as a known issue and advise Swissknife users to avoid Project tokens until CircleCI resolves this. I'm not a fan of putting my Personal token into the pipeline, but this seems to be the only way for the moment.

[roopakv]

@maciejb nice find.

Sadly i couldnt find a nice way to implement this with only the v2 API back then. However I know they are going to deprecate the v1 API soon so I will start doing some work to see if it is possible now :)

[maciejb]

Thakns @roopakv but the problem is with the v2 API, so upgrading the v1.1 to v2 won't solve it -- you would just get Exit 22 triggered earlier in the script :)

Seems like people have been asking for this and noting its poor implementation (404 instead of proper error) since v2 API came out, but it's been a few years now so I wouldn't hold my breath. Their support page recommends creating a service account user for such things and using a Personal Token.