feat(ci): add status check for new workflow

[aali309]

fixes: #283

[aali309]

pr [LINK]: (aali309#2)

workflow [LINK]: (https://github.com/aali309/cryostat-core/actions/runs/6710956726/job/18237467908)

When all tests pass: [LINK]: (https://github.com/aali309/cryostat-core/actions/runs/6711435447/job/18238795749)

[github-actions]

ARCH	IMAGE
amd64	ghcr.io/cryostatio/cryostat-core:pr-290-12aecf6971c78d528b22ae11ecfdcbe837790e18-linux-amd64
arm64	ghcr.io/cryostatio/cryostat-core:pr-290-12aecf6971c78d528b22ae11ecfdcbe837790e18-linux-arm64

To run smoketest:

# amd64          
CRYOSTAT_IMAGE=ghcr.io/cryostatio/cryostat-core:pr-290-12aecf6971c78d528b22ae11ecfdcbe837790e18-linux-amd64 sh smoketest.sh

# or arm64
CRYOSTAT_IMAGE=ghcr.io/cryostatio/cryostat-core:pr-290-12aecf6971c78d528b22ae11ecfdcbe837790e18-linux-arm64 sh smoketest.sh

[aali309]

/build_test

[mwangggg]

ah it failed because an image hasn't been built for this specific ref for your PR.. perhaps the CI build workflow needs to be triggered on more PR events- I'll take a look

[mwangggg]

Oh it's because you ran /build_test before the CI build workflow was completed- so those images hadn't been pushed to ghcr.io yet. In core, the /build_test command isn't to build and test the Cryostat image build with the new -core, it just runs the integration tests. The building of the image is automatically triggered by the pull_request_target events.

[andrewazores]

I guess putting the workflows in the same concurrency group and using cancel-in-progress: false could be a useful queuing behaviour for that kind of case, but I don't know if there would be other downsides associated with that, and I haven't put any thought into what to use as the concurrency group ID to tie those things together - I guess it would just have to be the branch name/checkout ref?

[aali309]

oh it's because you ran /build_test before the CI build workflow was completed- so those images hadn't been pushed to ghcr.io yet

yes, I figured after looking at the build again and I deleted the comment

[mwangggg]

@andrewazores Hmm if they're in the same concurrency group and the /build_test workflow is running, I guess whomever's PR it is will have to wait until it's done to push any changes - could cause an old image to be tested if they're not careful. But otherwise, I can't think of any other downsides?

[aali309]

@andrewazores Hmm if they're in the same concurrency group and the /build_test workflow is running, I guess whomever's PR it is will have to wait until it's done to push any changes - could cause an old image to be tested if they're not careful. But otherwise, I can't think of any other downsides?

This is what I ran into at first.

[andrewazores]

Maybe there would be a way to group those things into a concurrency group based on the latest commit hash, so that when a new push comes in that has a new hash and is therefore in a new concurrency group/separate queue? I'm not sure if this is really worth the time investment to get working, it's going to come up pretty rarely and the workaround is just to wait for the initial build completion before invoking the build_test workflow.

[aali309]

Maybe there would be a way to group those things into a concurrency group based on the latest commit hash, so that when a new push comes in that has a new hash and is therefore in a new concurrency group/separate queue? I'm not sure if this is really worth the time investment to get working, it's going to come up pretty rarely and the workaround is just to wait for the initial build completion before invoking the build_test workflow.

I agree about the time it might take to get this to work. May be something we can look at in the future?

[mwangggg]

we could add a step that checks if the image exists, and if not, exit with a message that informs the commenter to wait until the initial build and push is completed to try integration testing?

[aali309]

we could add a step that checks if the image exists, and if not, exit with a message that informs the commenter to wait until the initial build and push is completed to try integration testing?

yes, this was what I was thinking as well.

[mwangggg]

I guess putting the workflows in the same concurrency group and using cancel-in-progress: false could be a useful queuing behaviour for that kind of case, but I don't know if there would be other downsides associated with that, and I haven't put any thought into what to use as the concurrency group ID to tie those things together - I guess it would just have to be the branch name/checkout ref?

Also, I'm not sure if it's the best idea to have cancel-in-progress: false for these workflows. There could be lots of bot comments from relabelling etc. i.e.: #281

[aali309]

Took a lot of time, to conclude with this one. Many other solutions available but they will require a lot of code change. May be later we can look to make it like cryostat main to adopt the retest option?

[github-actions]

ARCH	IMAGE
amd64	ghcr.io/cryostatio/cryostat-core:pr-290-224612dd3cdfc59ec613da5504cb77c6f732e905-linux-amd64
arm64	ghcr.io/cryostatio/cryostat-core:pr-290-224612dd3cdfc59ec613da5504cb77c6f732e905-linux-arm64

To run smoketest:

# amd64          
CRYOSTAT_IMAGE=ghcr.io/cryostatio/cryostat-core:pr-290-224612dd3cdfc59ec613da5504cb77c6f732e905-linux-amd64 sh smoketest.sh

# or arm64
CRYOSTAT_IMAGE=ghcr.io/cryostatio/cryostat-core:pr-290-224612dd3cdfc59ec613da5504cb77c6f732e905-linux-arm64 sh smoketest.sh

[andrewazores]

Looks pretty good to me. Rebase please

[github-actions]

ARCH	IMAGE
amd64	ghcr.io/cryostatio/cryostat-core:pr-290-edc1af6c67152540f65b02cbcf265f6f0611b1c4-linux-amd64
arm64	ghcr.io/cryostatio/cryostat-core:pr-290-edc1af6c67152540f65b02cbcf265f6f0611b1c4-linux-arm64

To run smoketest:

# amd64          
CRYOSTAT_IMAGE=ghcr.io/cryostatio/cryostat-core:pr-290-edc1af6c67152540f65b02cbcf265f6f0611b1c4-linux-amd64 sh smoketest.sh

# or arm64
CRYOSTAT_IMAGE=ghcr.io/cryostatio/cryostat-core:pr-290-edc1af6c67152540f65b02cbcf265f6f0611b1c4-linux-arm64 sh smoketest.sh