@alexmurray
Your assumption is correct. It is the nightly build of neovim.
neovim has been published as you have suggested now for 2 years or more. This is not ideal though, because releases become a manual process. In our opinion, the ideal solution would be for the snapcraft build service to support a more robust API. There are several outstanding issues that have highlighted this same issue, but with little progress. For your reference:
This is my situation: I have a Flutter app on GitLab and a Github project for the snapcraft stuff which is connected to the snapcraft build server. So with one click in the snapcraft developer website I can build for all platforms and release it to the edge store and with one drag&drop I can push this to the release channel.
The problem is: One click and one drag&drop is very hard for extreme lazy people like me. I would like to trigger this from the GitLab CI. So on every commit in the main br…
Not at the moment, though I think that would be a reasonable thing to add. Could you file a bug for that, please?
My view is to be able to programmatically trigger a build without having to add a commit to the github repository. Answering your questions:
What do you mean by ‘webhook triggering third party snap build’?
A script or application hosted on my own infrastructure triggers the BSI build to initiate.
Where the snap code would be hosted?
GitHub
Where would snapcraft.yaml live (if upstreams are not willing to maintain snap package)?
GitHub
https://github.com/canonical/snapcraft.io/issues/2849
opened 08:16AM - 09 Mar 17 UTC
Priority: Low
Feature 🎁
I'm sure you know about that one, it's more for a tracking purpose.
You can't… build to a different branch than master, which could be handy in that you have maintainance and release branch. Seems like a good opportunity for build.snapcraft.io
opened 07:57AM - 27 Mar 21 UTC
Priority: Low
Feature 🎁
### Expected behavior
* Whenever the repo has created a tag, a snap build is … triggered for that tagged revision.
* The integration GitHub webhook should be triggered on either the `push` and `tag` event.
### Current behavior
The snap build is push-triggered, which, the tagged release snap will never be built if:
* It is not hardcoded in the snapcraft recipe via the `source-tag` attribute
* The developer doesn't push code at the timing when the default branch is pointed on the tagged revision.
Previously I made a script to work around this behavior([Selective-checkout: Check out the tagged release revision if it isn't promoted to the stable channel - doc - snapcraft.io](https://forum.snapcraft.io/t/selective-checkout-check-out-the-tagged-release-revision-if-it-isnt-promoted-to-the-stable-channel/10617)) but I believe it should be handled by the build system instead.
### Steps to reproduce the problem
1. Connect a Git repo to the Snap Store build system
2. Create a tag on the current revision
3. Create another commit, making the default branch not point to the tagged revision
4. Push the code to GitHub, notice that only the branch pointed revision is built instead of the tagged revision
With little to no attention to these issues, the only feasible solution for our use case is to one either cease providing nightly builds, or provide two different snaps. I have personally kept on eye on these various issues for awhile, and have been reluctant to implement the latter solution.
With little to no progress on the issues though, I honestly see no other path forward.
