Official snap for Snapstore

[casabre]

I would love to be able to deploy redis as a snap in my setup. Thus, I created a recipe in order to build the snap successfully. Unfortunately, I cannot release it at the Snapstore because the package name "redis" is reserved for official packages by the developer.

Hence, I would ask if it is possible to transfer the ownership of my repository to antirez and that you are applying for the official package name. In the end, I could offer to maintain the package and the recipe.

Does this sounds reasonable to you? Thanks

[yossigo]

@casabre thanks for this and the offer! I've submitted a request to get hold of the redis package name.
I am not sure if it would make more sense to pull the recipe into the Redis main repository or maintain a dedicated repository for this.

[casabre]

@yossigo you are welcome and I would be happy to contribute.

Regarding a dedicated repository, I would stick with it because if you link the repository with the snapstore, one can utilize the provided CI which is building and publishing the snap. Sounds more reasonable to me but it’s up to you 😉.

[JonasKruckenberg]

So it seems I'm a bit late to the party 😅

EDIT: I deleted my previous message after cloning your repo. I was originally proposing my config but I will just point out what I would change instead.

While creating a separate repository has a lot of benefits such as being a place for snapcraft specific discussions, issues, and docs, it has however a pretty significant downside as I'll point out below.

There are a few questions left though, I'm gonna list them here in no specific order:

1. When should the repo trigger builds and publish new versions?
   The simplest and I think preferred way would be to have build.snapcraft.io publish an edge build on every push to the repo, and promote builds manually ( This is I think how snapcraft handles things by default )
   This raises an issue though when we set up the snap as it's own repo one would have to commit every time a new edge build should be released. This is not ideal as the edge channel should be always up to date with the unstable branch in my opinion.
   There is also the question of tags, I think github tags with -rc* at the end should publish latest/candidate releases while tags with nothing should publish a latest/stable release.
   I don't know though how one would set this up.
2. As you can see in my fork
   I changed the commands so they don't have redis- in front of them. This makes the commands available as redis.server, redis.cli, and so on instead of redis.redis-server.
   This could be later changed back to redis-server etc. with alias request from the snap store.
3. I think there should be a system in place ( via the configure hook ) To change the redis configuration from the standard snap get, snap set, snap unset interface.
   Maybe a shell script that writes the changes to the actual redis config file or something, this would be a great developer feature.

Further changes I implemented in my fork:

• I made the redis server a daemon so it starts automatically.
• I also made the snap use core20 ( now that it's considered stable why now use it? )
• Maybe you can enlighten me what the tcl8.5 dependency is good for, but it was giving me errors so I removed it
• I added libssl-dev and compiling with tls support
• As I said we'd need a more sophisticated release system, but for now I switched the snap to use the redis repo at the 6.0.6 tag.

The big question remains, should we put the snap config in a separate repo and pretty much give up on building edge and candidate releases?
Or should the snap be integrated into the main repo without the separate discussion forum?

I'd vote for integrating it into the main project as publishing a new edge release on every github commit, a candidate on -rc tags, and a stable on normal tags seems the most optimal for me. This could be archived with a bit of shell magic and the snapcraftctl set-version statement. But this decision is ultimately not up to me to decide.

I know this is a lot, but I just want to help ( and also use the redis snap 😃 )
Cheers!

EDIT: I played around with my proposed versioning script and found that on the unstable branch it already completely breaks because the tag name is too long for a snap version. Oh well...

[yossigo]

@casabre @JonasKruckenberg After some consideration and discussion with other Redis core team members, I've adopted the separate repository approach. As we'll push for more native packaging, it makes sense to keep the core repository clean.

We'll be sure to integrate Snap releases in any official/RC version released anyway, and I think running a daily job of building the latest unstable is probably frequent enough.

I've done some basic work to automate building and publishing of an unstable version as an edge. I'll appreciate if you can have a look and suggest any improvements/fixes you see fit! I have absolutely no familiarity with the snap ecosystem so I may have done lots of dumb things, don't spare me please.

Any further discussions/PR can probably go to the new repo.

[casabre]

@JonasKruckenberg thanks for your thoughts on this and sorry for the late reply. @yossigo thanks for setting up a new repository.

When should the repo trigger builds and publish new versions?

I am not sure how can we manage this fully automated. Maybe some connected actions which are updating the version in the snap repo because I believe that not that much modifications are necessary in the recipe. However I am not sure if an automated trigger of builds.snapcraft.io is possible? Do you have more experience on this side?

As you can see in my fork

Just left the original commands because I wanted the alias replacement after publishing by the snap store

I made the redis server a daemon so it starts automatically.

This is great. I just used it as initial playground

I also made the snap use core20 ( now that it's considered stable why now use it? )

Usually I would agree but do we have much more benefits from switching compared to the core LTS 16.04? With LTS 16.04 core compatibility, I believe we can reach much more users

Maybe you can enlighten me what the tcl8.5 dependency is good for, but it was giving me errors so I removed it

Honestly, I can not remember but I believe that it was a build dependency for the snap core.

@yossigo I had just a quick glance but from my side LGTM.

[yossigo]

@casabre Thanks, I will wait for more feedback before putting together a more stable 6.0.6.
Redis only uses tcl8.5 for testing, it can be safely skipped.

[JonasKruckenberg]

However I am not sure if an automated trigger of builds.snapcraft.io is possible? Do you have more experience on this side?

I actually don’t know, the last time I tried I couldnt get it to work on anything other than push, but I'll do some more testing tomorrow.

Usually I would agree but do we have much more benefits from switching compared to the core LTS 16.04? With LTS 16.04 core compatibility, I believe we can reach much more users

I think the core snap doesn't really matter when it comes to compatibility, for example I can install the redis base20 snap on my ubuntu 16 VM without problems. But maybe there are more subtle differences that I don't know of

[yossigo]

The unstable snap got no rejects, so there's now a stable 6.0.6 snap as well + a daily job to create the latest unstable. Closing the issue now, anything that is snap specific should be reported in the Redis-Snap repository.

Thanks @JonasKruckenberg and @casabre for your help!