Build standalone script edition in CI

[alerque]

Fixes #202.

I debated whether to call this special build "bootstrap" or "standalone". In the end "standalone" made more sense to me, but if anybody has a stronger opinion mine is pretty weak.

The idea is to just use the existing build system but tweak it to:

• not build any of the extras like man pages or completions
• not actually detect anything about the host environment, have it just assume $PATH will work at runtime
• add a -standalone segment to the version string so bug reports are easier to identify
• post the resulting script as an artifact on all CI jobs
• attach the resulting script "bare" (with no version info in the filename) to releases so that it can be downloaded using a oneliner, e.g. curl -fsLOJS https://github.com/RichiH/vcsh/releases/latest/download/vcsh-standalone.sh

[alerque]

Unfortunately due to the way GitHub Actions is setup the standalone version artifact attached to each CI run here can only be downloaded as a zip file. You can see it as built for this PR here. This isn't very conducive to oneliners, but I think that's okay. If people are going to script this they shouldn't be using some random CI run artifact anyway.

The standalone script attached to each release should download as a bare script ready for execution by a shell. It's kind of hard to test that until we actually tag a release, but I'll try to do a prerelease on my fork and see if it works there.

[RichiH]

What about "hosting" on https://pages.github.com/ ? We could have a shell script there.

Minor nit, @DEPLOYMENT@ might make more sense, as that could also cover e.g. vcsh-git for development.

[alerque]

What about "hosting" on pages.github.com ? We could have a shell script there.

Yes, this could be hosted on GitHub pages. What would be the advantage to that over attaching the script to releases? The disadvantage I see in moving to Pages is the disconnect from the tagged versions. Of course we could host multiple versions there with something matching the tag versions, but with artifacts attached to releases the relation to the release cycle seems more clear and it would encourage people to use a tagged version while still giving the option of using the latest keyword in place of a tag version.

[alerque]

Minor nit, @DEPLOYMENT@ might make more sense, as that could also cover e.g. vcsh-git for development.

I don't have a problem with @DEPLOYMENT@ over @EDITION@, but it would have no effect on development versioning. Development versions (anything not built from an exact tag release) already have an elaborate version string with the last tag, the number of commits since the tag, and the commit hash. We don't need anything else to identify them, this would be purely for identifying the type of installation that was used.

I don't know if there will be use for any other build types, but does ./configure --with-deployment=standalone make more sense than ./configure --with-edition=standalone? If so I'm happy to rename.

[RichiH]

Yes, this could be hosted on GitHub pages. What would be the advantage to that over attaching the script to releases

That it's vcsh-standalone.sh, not vcsh-standalone.zip. It should always point to latest, agreed.

[RichiH]

does ./configure --with-deployment=standalone make more sense than ./configure --with-edition=standalone?

I think it makes slightly more sense, yes.

[alerque]

Yes, this could be hosted on GitHub pages. What would be the advantage to that over attaching the script to releases

That it's vcsh-standalone.sh, not vcsh-standalone.zip. It should always point to latest, agreed.

The standalone scripts attachments to releases will not be ZIPs anyway, they should download as plain text ready for reading by a POSIX shell. That caveat only applied to the CI runs for every commit/PR.

[alerque]

For a real preview of what I expect this to look like, I tagged a sample release on my fork. Check out this simulated v1.9.0 release. See the artifacts? Is that clear that there is a source release (tar.xz and zip) plus a standalone raw shell script attached? For testing you should be able to:

$ curl -fsLOJS https://github.com/alerque/vcsh/releases/download/v1.9.0/vcsh-standalone.sh

...for direct download of the script via the tag or:

$ curl -fsLOJS https://github.com/alerque/vcsh/releases/latest/download/vcsh-standalone.sh

...for the latest keyword version with no tag name required. (Note the reversal of path segments when using the keyword is correct!)

[alerque]

Sorry for the noisy pushes in this PR, most of them don't have any bearing on the discussion above. I was using this as as excuse to shake down the CI jobs handling lint/test/build/release chores. The process seems pretty solid now, for example here is a simulated v1.9.1 release where the build artifacts (source dist plus standalone script) as well as the changelog notes are all posted automatically.

[RichiH]

Minor nits, else LGTM, thanks!

[RichiH]

It's a tad noisy but my workflow hides most of this, no worries. And thanks for actually doing the work! :)

[nferch]

Thanks @alerque and @RichiH for all of the work and review on this!

Sorry if I missed this, but is there an issue or PR to track the first release that will contain this and make https://github.com/RichiH/vcsh/blob/main/doc/INSTALL.md reflect reality?

[RichiH]

Good point. #301 is the tracking issue which will result in a new release being built.