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

Build related 0.43 tasks #4908

Closed
bep opened this Issue Jul 6, 2018 · 20 comments

Comments

Projects
None yet
5 participants
@bep
Member

bep commented Jul 6, 2018

  • Update Goreleaser with a new set of binaries for Win, MacOs and Linux (for now)
  • Finish the Docker image for the above
  • Snap? I assume we leave it as is for now. @anthonyfok
  • Talk to the Brew people.

@bep bep added this to the v0.43 milestone Jul 6, 2018

@anthonyfok

This comment has been minimized.

Contributor

anthonyfok commented Jul 8, 2018

Snap? I assume we leave it as is for now. @anthonyfok

I have just started tweaking snapcraft.yaml and experimenting with the extended-snap branch, which https://launchpad.net/~gohugoio/+snap/hugo-dev is now temporarily tracking and making test builds for me. :-)

@bep

This comment has been minimized.

Member

bep commented Jul 8, 2018

Re. snap, is it possible to deliver 2 versions? I assume there will be people wanting a "pure Go" Hugo version and does not need the SCSS/SASS.

@anthonyfok

This comment has been minimized.

Contributor

anthonyfok commented Jul 8, 2018

Re. snap, is it possible to deliver 2 versions? I assume there will be people wanting a "pure Go" Hugo version and does not need the SCSS/SASS.

I think it is possible. Would you like two separate executables in the same snap (easier to do), or two entirely separate snaps?

Assuming the first case, how would you like to name the executables? How about hugo and hugo.unextended?

@bep

This comment has been minimized.

Member

bep commented Jul 8, 2018

hugo and hugo.unextended?

... Unextended?

No, I was more thinking some "snap target" (I'm not sure what that is) ... like dev, extended.

If two binaries, then the default should be the one without change, ie. hugo and then hugo-extended.

But I'm thinking out loud here.

@bep

This comment has been minimized.

Member

bep commented Jul 8, 2018

Note that the binaries on the release page will be named "hugo" and "hugo_extended"; I think I want them to be named the same, but that will have to wait.

bep added a commit that referenced this issue Jul 8, 2018

@anthonyfok

This comment has been minimized.

Contributor

anthonyfok commented Jul 8, 2018

No, I was more thinking some "snap target" (I'm not sure what that is) ... like dev, extended.

Snaps can be released into 4 channels, namely "stable", "candidate", "beta" and "edge". IIRC, hugo-dev is just a random name I picked for the build daemon (?) that tracks the hugo master branch for the most cutting-edge builds, and have them uploaded and published directly into the "edge" channel, but the name hugo-dev itself doesn't actually appear anywhere in the snap itself, and snap has no knowledge of that name.

So, to install what I named hugo-dev on Launchpad, the end user would actually use snap install hugo --edge, and not snap install hugo-dev.

While we can create an entirely new snap called hugo-extended, that seems a bit too complicated to me, especially we would have to maintain an extra branch with a special snapcraft.yaml that says name: hugo-extended on its the first line.

At least that is my (limited) understanding of it.

If two binaries, then the default should be the one without change, ie. hugo and then hugo-extended.

Since most end users do not compile Hugo from source and instead use whatever release binaries are provided to them, I and since Hugo with SCSS support is such a hot feature, I actually think that most people would prefer using the full Hugo (with extended build tag) and wouldn't worry too much about the enbedded C LibSass. (i.e. most Hugo users do love Go but are not Go purists, or most likely don't even know how to write in Go code.)

For me, with my "end user" hat on, I would rather prefer having one single binary but with a runtime flag to disable the SCSS feature if I were to keep using gulp or something else to build my SCSS files.

But that's just me and my guess. I could be wrong. ;-)

Note that the binaries on the release page will be named "hugo" and "hugo_extended"; I think I want them to be named the same, but that will have to wait.

Is that due to Gorelease not yet being ready for them to be named the same? Or for some other reasons?

@anthonyfok

This comment has been minimized.

Contributor

anthonyfok commented Jul 8, 2018

Is that due to Gorelease not yet being ready for them to be named the same? Or for some other reasons?

I should have looked more carefully. You've already opened #4916. ;-)

@bep

This comment has been minimized.

Member

bep commented Jul 8, 2018

I spent 8 hours yesterday to get Windows and Darwin builds from a Docker container, and today has also been a whole lot of other troubles, so I think I will postpone the Snap discussion.

@vsopvsop

This comment has been minimized.

Contributor

vsopvsop commented Jul 9, 2018

Instead of hugo-extended can it be named just hugo+

Hugo Vs. Hugo-plus benchmark

@caarlos0

This comment has been minimized.

Contributor

caarlos0 commented Jul 9, 2018

About snaps: goreleaser can generate them as well, but it doesn't publish them for now... (there is an issue for that)

Once goreleaser can also publish, it would be straightforward to have 2 snaps IMHO...

anthonyfok added a commit that referenced this issue Jul 9, 2018

snap: Build both hugo and hugo.extended for 0.43
Due to snap's design, the name "hugo_extended" needs to be created
via an automatic alias request, see
https://forum.snapcraft.io/t/hugo-auto-alias-request-for-hugo-extended-hugo-extended/6297

Also migrate from deprecated "prepare", "build" and "install" keywords
to "override-build".

See #4908
@anthonyfok

This comment has been minimized.

Contributor

anthonyfok commented Jul 9, 2018

I spent 8 hours yesterday to get Windows and Darwin builds from a Docker container, and today has also been a whole lot of other troubles, so I think I will postpone the Snap discussion.

I didn't quite realize the full complexity of the using-Docker-for-Windows-and-Darwin-builds when I first read your tweet, but after seeing what you wrote above, and starting to think about it... Wow, huge task indeed! You are amazing as always!

Meanwhile, the Snap build with two binaries is a lot more trivial and seems to be working. I'll make more tweeks and try to match the names hugo and hugo_extended as much as possible.


several hours later


Changes to snapcraft.yaml pushed to master in commit e1027c5.

Due to snap's design (to avoid namespace collision), hugo.extended can be readily made accessible but not hugo_extended. The latter will hopefully be available in a week or two, see the "automatic alias" request at https://forum.snapcraft.io/t/hugo-auto-alias-request-for-hugo-extended-hugo-extended/6297

@bep

This comment has been minimized.

Member

bep commented Jul 9, 2018

@anthonyfok not sure I understand; In the main release we package it in several archives (one extended, one not), but with the same binary. A user wants one of them, not both. So we don't need (want?) different binary names, that would lead to confusion. Does the user have to typo "hugo_extended ...?"

bep added a commit that referenced this issue Jul 9, 2018

@anthonyfok

This comment has been minimized.

Contributor

anthonyfok commented Jul 9, 2018

@anthonyfok not sure I understand; In the main release we package it in several archives (one extended, one not), but with the same binary. A user wants one of them, not both. So we don't need (want?) different binary names, that would lead to confusion.

Does the user have to type "hugo_extended ...?"

Yes, with the current snapcraft.yaml that I just committed.

So, would you prefer that Hugo snap users use snap install hugo to install the pure-Go version, and use snap install hugo-extended to install the "extended" version, and in either case, the end users simply run hugo?

If that is the case, I think we'll need to have a separate snapcraft.yaml with the first line name: hugo changed to name: hugo-extended, and probably have that "extended" snapcraft.yaml live on another branch, say "master-extended-snap", and maybe "stable-extended-snap", and probably have these branches automatically rebased and updated from "master" and "stable" with some kind of automated git hook. I could go and set up a new snap called "hugo-extended" now on the snapcraft dashboard web interface and pursue that route.

anthonyfok added a commit that referenced this issue Jul 9, 2018

snap: Migrate from deprecated keywords to "override-build"
Also add verbosity and echo messages to aid debugging.

See #4908
@anthonyfok

This comment has been minimized.

Contributor

anthonyfok commented Jul 9, 2018

Good call in reverting the multi-binary snapcraft.yaml! hugo.extended or hugo_extended is confusing to the end user, not to mention that the bash completion does not work with hugo_extended. ;-)

I went ahead and began a new experimental snap named hugo-extended built from master-extended-snap extended-snap-master intended for the "edge" channel. It is currently building at:

And should eventually show up at:

For the time being, the wrapper executable is called /snap/bin/hugo-extended 😛 unless the end-user set up an alias with

snap alias hugo-extended hugo

or until 7-day voting period after we file a request for "automatic alias" that is managed at the Snap store:

I think we can wait a week or two until all these are sorted out before asking a few volunteers to test and give feedback. :-)

@bep

This comment has been minimized.

Member

bep commented Jul 9, 2018

I'm into all sorts of "does not work" on CircleCI, which is my third day in a row with nothing but trouble ... I think this is a sign from above that I need a vacation ...

@anthonyfok

This comment has been minimized.

Contributor

anthonyfok commented Jul 9, 2018

Hang in there! Getting these CI things are very tricky indeed, not to mention such a complicated cross-platform setup with Docker! You are our fearless leader! We have full trust in you!

(If you wish, I'd be more than happy to help, though admittedly my experience with Circle CI and Docker are minimal.)

@bep

This comment has been minimized.

Member

bep commented Jul 9, 2018

The CircleCI thing was my fault; I had slipped with some Git resets... I'm getting there...

@klakegg

This comment has been minimized.

Contributor

klakegg commented Jul 9, 2018

Is the extended edition supposed to be a permanent solution? We're talking 2 MB extra, so I can't at the moment see the benefit of having two editions.

Do you see other features becoming exclusive to the extended edition in the future?

@bep bep closed this Jul 9, 2018

@anthonyfok

This comment has been minimized.

Contributor

anthonyfok commented Jul 9, 2018

Just a final comment on this issue related to our Snap setup for the "extended" build of Hugo:

The Snapcraft experts recommend the use of tracks to us, which was unbeknownst to me. (/me embarrassed):

@chipaca (John Lenton) wrote:

hmm, reading that issue, wouldn’t it make more sense to have a single hugo snap, with an extended track ?

@roadmr (Daniel Manrique) wrote:

Hi,

In principle this seems to fit the use case for tracks:

snap install hugo <- non-libSass version
snap install hugo --channel=extended  <- libSass version

Just be aware that you will need to publish the corresponding binaries to the matching track, otherwise > people tracking extended will not receive updates.

Also, each track has its own independent set of risks (stable, candidate, beta, edge), so this also works:

snap install hugo --channel=extended/beta

I’m +1 to giving a track for Hugo to maintain this extended version “in parallel” with the traditional one.

Per the process, there’s a voting period, at the end of which we’ll look at the votes from reviewers (mine included) and act on the track request. Thanks for your patience!

  • Daniel

I think this is also something that @bep has in his mind in the first place. And, indeed, the Skype Snap is also using the track feature for its "insider" build. No need for "two executables" or a separately named hugo-extended snap complexity.

As of today (2018-07-09), we are into the 3-day (or 7-day?) review/voting period for the creation of an extended track for the existing hugo snap.

I'll be tracking this personally over the next few days, and will build the snaps for both the default track and the "extended" track when it is ready.

@caarlos0

This comment has been minimized.

Contributor

caarlos0 commented Oct 22, 2018

About snaps: goreleaser can generate them as well, but it doesn't publish them for now... (there is an issue for that)

Once goreleaser can also publish, it would be straightforward to have 2 snaps IMHO...

FWIW, GoReleaser can now publish snaps: https://carlosbecker.com/posts/goreleaser-snap-travis/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment