Feature request: build on successful checks

[frankier]

Links

• container collection: https://singularity-hub.org/collections/4494
• GitHub repository or recipe file: https://github.com/frankier/skelshop/blob/master/Singularity

Error on Singularity Hub

No error, but it doesn't build on a successful deployment. Looking at GitHub webhooks the latest has received the response: {"status": "Received, building disabled."}, but I have re-enabled building beforehand.

What do you think is going on?

SingularityHub still thinks building is disabled for some reason?

[vsoch]

hey @frankier - building is certainly not disabled, and the message is indicating that the standard commit -> build is disabled, which it is, because you collection is set to deploy on DEPLOYMENT (which must be triggered from a CI service). If you want to change your collection to build on a commit or manual trigger, then you need to change the build trigger. If you are having difficulty still, I would suggest:

1. testing manual build
2. sending me the payload (without secrets!) from the webhook so I can take a look. Email would work.

But not now, because it's bedtime :)

[vsoch]

And here is more information about what it means to trigger based on deployment: https://singularityhub.github.io/singularityhub-docs/docs/builds/deployment

[frankier]

The GitHub documentation is a bit all over the place now, but I now get the idea this would mean pinging the GitHub API with curl or something to create a new deployment event/object, while making sure to protect my personal authorisation key. This is a bit complex for simple cases where we just want to run some tests and only build when they pass.

So may I instead rather cheekily make issue into two feature requests:

1. Change webhook response to give more fine grained reason e.g. "Not building because only building on deploy event"

2. Make another trigger type: "push + successful commit". It would listen for this webhook: https://developer.github.com/v3/repos/statuses/ and build when "state" == "success". This way, it should "just work" with a default configuration of most external CI providers.

[vsoch]

The GitHub documentation is a bit all over the place now, but I now get the idea this would mean pinging the GitHub API with curl or something to create a new deployment event/object, while making sure to protect my personal authorisation key. This is a bit complex for simple cases where we just want to run some tests and only build when they pass.

It's much simpler than that, when you use CI services and they are connected via "GitHub checks" a similar webhook is sent out to attached services. You as a user do not need to do any sort of "pinging with curl" or even interact with an authorization key. When the webhook is created, a secret is shared with singularity hub that is used to validate the payload. All the user needs to do is check which kind of webhook event to respond to, commit, or deployment. It's really not complex - if you would like to improve the docs it's all on GitHub and your contribution would be greatly appreciated.

Change webhook response to give more fine grained reason e.g. "Not building because only building on deploy event"

Thanks for your feedback. I will take this into consideration for some future update.

Make another trigger type: "push + successful commit". It would listen for this webhook: https://developer.github.com/v3/repos/statuses/ and build when "state" == "success". This way, it should "just work" with a default configuration of most external CI providers.

This is a nice suggestion, but the issue here is that the status is successful in many cases when a deployment is not done. Since deployment is considered the "we've merged, the CI is done and successful," this is the use case that Singularity Hub supports. Let me know if you have any other questions, happy to answer.

[vsoch]

More information on the deployment event and then for example, how to trigger a deployment from a CI travis. If you want to meet the use case of "do a build when all checks pass" this would be functionally equivalent to having a trigger of commit to master, which you would then require a PR with passing tests to do.

[frankier]

Thanks for the info. Working to condense some of this higher level info into the docs.

[vsoch]

Thanks again for your help with the docs @frankier ! https://singularityhub.github.io/singularityhub-docs/docs/builds/deployment.

[vsoch]

I think we've addressed the issue and updated the docs, so going to close. Thanks again @frankier !