-
Notifications
You must be signed in to change notification settings - Fork 60
Snap packaging for jd #81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
@Hook25 thanks for putting this up! Yeah, I would love to have this. I don't use snap but I want jd to be available easily however people get their tools. Have someone look it over and we'll put this up when you're ready. I'll try out snap in the meantime. Thanks!! |
pedro-avalos
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, I'm a colleague of Massimiliano. I have done some snap packaging, and he asked me to take a look at this PR. Here is my initial feedback. I will try to take a closer look this weekend.
|
@Hook25 @pedro-avalos can you update this to track 2.x.y releases? The latest is 2.0.1. I will be backporting only security fixes to the 1.x.y series. Perhaps we can use tracks? |
| ls | ||
| mv release/jd $CRAFT_PART_INSTALL/ | ||
| # extract the version from main.go and set it as the snap version | ||
| VERSION=`grep "const version" main.go | grep -oP '"[\w\.-]+"' | grep -oP "[\w\.-]+"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be more stable to rely on the -version flag. E.g. go run . -version. Output looks like jd version HEAD and I will keep it stable, even if I change the way the version number works (e.g. if I provide it as a build parameter).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello, sorry I kinda abandoned this here. The point of that line is to extract an actual version from jd (as it doesn't seem to return the semver version from the -version flag if you run it from source, can't recall if this was intended). Regardless, the version is not a valid snap version as it can't contain spaces, and it is pretty useless (imagne downloading version HEAD from the store!).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code at HEAD doesn't have a version (it just returns HEAD). But the release binaries and associated tagged sources do. So you should be packaging a released version, not one built from head. You can still build from source, but you should should build from a released source.
Co-authored-by: Pedro Avalos <[email protected]>
|
As for the release, you can use tracks, but I would probably just use 1 release channel. I didnt do anything on the store side, so I don't know what you mean by update this. Do you want me to rebase this on the current master? |
I don't know anything about the snap packaging format. But essentially you want to avoid packaging and releasing from HEAD or |
Somehow And the So you should be able to. |
Hello, I have created a small snap for jd and use it daily! Shout out for the really nice job, it is super useful. I thought you may like this so here it is.
This is more of a conversation starter, if you like what you see (namely, you want to have the possibility to build a snap), please comment here, I will get someone who is better than me with snaps to actually look this over!
The snap should work as normal jd (it allows you to host the server and use it from the cli). To build it run: