I’ve noticed in the past few weeks that the Snapcraft Build Service is generating releases without a Github Webhook being involved. Specifically, it is overwriting edge with new releases, as if a webhook had been sent properly, bar the fact the webhook has never been triggered.
As an example, for the package
weka-james-carroll, launchpad builds #1076762 #1078956 #1099157 were all generated with no valid reason. It is not the only snap I have doing this. I did not press the request build button and Github says the last webhook sent for the associated repository was before any of these builds happened.
I can imagine this being potentially wanted behaviour, frequent rebuilds to update packages in the snap are good for maintenance, however I can also imagine that this could potentially break some workflows if edge is being overwritten with no one being involved in the process at all, such if some packages become unresolvable or parts change unexpectedly. Admittedly it’s expected that users using the edge channel might find it broken unexpectedly for whatever reason, but if the maintainers don’t even realise edge is changing without them being involved, there’s possibility for confusion.
I am leaning on thinking this is a bug but I’m curious if perhaps this is something that’s undocumented or I’ve simply not seen before. Is this something that needs escalating?
Thanks for reading!
Maybe it is initiated by the periodically security scan? Not sure…
It’s possible that the build service is not correctly identifying that you have set a
source-commit in your Weka part and triggering builds for any changes to the upstream repository. The service is designed to automatically rebuild if your dependencies’ git repositories change, but it is likely being over-zealous in this case because you have specified a commit-hash instead of using a branch e.g. the main branch.
Thanks for the responses,
Being rebuilt due to security would make sense to me, but I don’t think it’s the reason in this instance. Given Snapcrafts emails about security updates to Ubuntu packages don’t trigger automatic rebuilds, I don’t think there’d intentionally be two different approaches to security updates, especially given without the email notification it might simply never be pushed due to lack of awareness.
Being rebuilt due to use of
source-commit is an interesting idea. There does seem to be some correlation between upstream commits and rebuilds, but it’s hard to say with 100% certainty due to delays between them occuring ( probably a timeout between the store checking for updates ). I wasn’t actually even aware the build service checked for changes in the parts themselves, so that alone is useful information to me.
I do have other packages that had this issue and don’t use
source-commit, although some do use
source-tag ; unfortunately Weka was the easiest to notice this happening with due to a slow release cadence and the others are buried in an avalanche of ‘proper’ builds. I’ll keep and eye out for when it happens on the other Snaps and see if they do correlate to upstream Git activity there, but given the frequency of the problem it might take a few weeks.