lab ci wait

[temp]

I don't know wether or not this is possible, but it would be nice to have a ci command that simpy waits for the current pipeline to finish and then exits with status code 0 for success, and 1 for failure.
This would allow scripting of several pipelines that need to be run in a specific order. I know you can trigger builds inside a pipeline, but we need it the other way - like a listener.

This would allow something like this:

cd /whatever/docker-base
lab ci create
lab ci wait
cd /whatever/docker-project-that-uses-docker-base
# or maybe
lab ci create --wait
cd /whatever/another-docker-project-that-uses-docker-base
# or maybe
lab ci create
lab ci trace --exit-on-finish
...

[zaquestion]

I'm pretty sure we can pull this off! Thanks for including your usecase as well, that goes a long way in integrating your idea into lab as a whole and provide a tangible workflow to justify implementation.

That said, have you looked at multi-project pipelines in GitLab? This may fit your usecase more elegantly that the feature would?? https://docs.gitlab.com/ee/ci/multi_project_pipelines.html -- Let me know!

[temp]

Yes, I looked at multi project pipelines, but they don't support our use case.
We don't need a trigger from upstream, but a listen from downstream.
Like in my example a base docker image.
Now for example 10 projects use this base docker image, and every time the base docker image is built, I want the 10 project docker images to be rebuild. But I don't want to add trigger code for each project in the base docker repository...

[zaquestion]

@temp lab ci status --wait was added in 0.15.0 please let me know if this works for your purpose and reopen if needed.

[temp]

Looking good!
Maybe the spam-factor can be reduced by waiting a second between status-check while --wait'ing? Or add something like --quiet?

[temp]

Ah, some weirdness remains ;-)
I have a status --wait running, and it's still printing running messages, but a status on a second console reveals:

± lab ci status
Stage:   Name              - Status
...
Pipeline Status: failed

Maybe the wait is already done, but he's still busy printing?

[temp]

Wow, it kept running, and Mac OS just complained about no app memory left...
Here's what it said:

:-D

(yes, I have enabled unlimited scrollback lines...)

[zaquestion]

Oh my!

[zaquestion]

@temp Not sure what you may have ran into, but at least in my own usage of this:

lab ci trigger some/other/project ...
lab ci status --wait # no way to actually specify project.

Going to fix that, have you been able to gather any more info on what you may have ran into? Is it possible that you also needed to specify a separate pipeline?

[temp]

@zaquestion I started it from within my git-directory - then you don't need to specifiy the project!
And then the described behaviour occurs.

[zaquestion]

Ah, nice work around! I'll add the additional means as well soon

[claytonrcarter]

I've also encountered this. lab ci status --wait doesn't ever seem to return. As I read the code (you know my Go ain't great), it looks like it never actually retrieves an updated list of CI jobs and just loops over the first list it received ... which makes sense why it would never update! :)

[zaquestion]

Yep @claytonrcarter is right, my code was just bunk 😊

[bmeneg]

@temp not sure if it's still a problem for you, but it should've been fixed with PR #361.
Please, feel free to let me know if it's not solved or if any other issue appear.

[temp]

@bmeneguele works fine now! 👍
it would be awesome to be able to specify the wait-seconds, but this is really nice-to-have... ;-)

[bmeneg]

@bmeneguele works fine now! 👍

I'm glad to hear that :)

it would be awesome to be able to specify the wait-seconds, but this is really nice-to-have... ;-)

Hmm... a timeout behavior? That's something to think about indeed.
Why don't you open a new issue with this suggestion so we can check it more "formally"?
It should be easy to make it happen.

[temp]

Hmm... a timeout behavior? That's something to think about indeed.

Oh, no, I meant the wait time between 2 polls. Have seen the 1-second-wait in the sources. But for long running pipelines it would be ok to poll 5-15 seconds, to avoid hammering. Like I said, it's only a nice to have.

[temp]

Here is the snippet:

// don't spam the api TOO much
time.Sleep(1 * time.Second)

[claytonrcarter]

Yup, when I fixed this feature, I picked 1s out of thin air! Adding a flag to configure the polling interval would be a trivial change; a great first issue/PR.

[bmeneg]

Ahh, got it!
Yes! for sure it would be a really nice "first issue".