feat(CI): Add CI and nothing else

[dark0dave]

@FredrikLindgren I've reduced the noise here. Hopefully its a bit more acceptable.

[dark0dave]

Hopefully you can see the run here: https://github.com/dark0dave/weidu/actions/runs/20197911536

If not:

[dark0dave]

I've tried to minimize the changes made, so its easier to accept this pr.

• Removed the windows line endings from the scripts files
• Removed the reference to the old hash table (required for modern ocaml), these form the basis of the fixes from nix.
• open_out_bin over open_out for windows compatibility (Ie I had trouble building it in windows powershell, this resolved @Argent77 issue)
• Add .gitattributes file to prevent windows line endings from ever being a problem again.
• I moved the zips to the current direction (Makefile changes) this is required for the CI, putting them a directory above doesn't work. This is tested in the CI, ie if the zip files are not present the CI fails.
• I've used export OCAMLDIR = $(shell dirname $(shell which ocaml)) over hard coding the location of ocaml, again this is essential for builds and just generally for anyone who uses opam or any other path for ocaml.

[dark0dave]

Please let me know if you have any questions.

[FredrikLindgren]

I think it looks really good!

A few questions, as much of this is new to me:

• What decides what to build and how does it make the choice? Like, what decides between main and release and which factors go into the decision?
• Where are the variables coming from? Like github.token and others.
• Do we have a choice beyond Ubuntu-latest? Binary compatibility with Ubuntu LTS, and I guess I should also throw in Debian, has been requested.
• Whose somebody else's computer is this running on?

And two remarks: the zips need to include README-WeiDU.html. I've also been distributing TisPack and MosPack as a convenience for the user base, but I imagine this might be hard to swing with this system.

[dark0dave]

What decides what to build and how does it make the choice? Like, what decides between main and release and which factors go into the decision?

If you push a tag, the release is auto generated, ie:

git tag v251
git push origin v251

This would trigger a build and a release. The zips are then bundled into the release, example:

https://github.com/The-Mod-Elephant/weidu/releases/tag/v250.01

On a pull request (PR) the builds are run. Once an pr is merged build is run again and those built zips are added to a nightly release (github terms pre-release). We can configure this however you like :).

Just let me know the desired behavior you want if the above is not too your liking.

Where are the variables coming from? Like github.token and others.

This are part of the runtime github provides, you can read more about them here: https://docs.github.com/en/actions/reference/workflows-and-actions/variables

The github token is the default token the job is run with

Do we have a choice beyond Ubuntu-latest? Binary compatibility with Ubuntu LTS, and I guess I should also throw in Debian, has been requested.

Yes! So read: https://docs.github.com/en/actions/reference/runners/github-hosted-runners. Additionally we can build inside the docker image provided! I can create Docker images for your exact specification, ie: https://hub.docker.com/_/debian, etc etc

There is even an option for self hosted runners: https://docs.github.com/en/actions/reference/runners/self-hosted-runners

Whose somebody else's computer is this running on?

@Argent77, @AngelGryph and @Incrementis (and obviously myself) and a few others have tested these binaries. Windows, mac and linux. There are some nix builds if you are so inclined as well.

[dark0dave]

And two remarks: the zips need to include README-WeiDU.html. I've also been distributing TisPack and MosPack as a convenience for the user base, but I imagine this might be hard to swing with this system.

I'll add the readme. For the other files, can we skip them for now?

[FredrikLindgren]

@Argent77, @AngelGryph and @Incrementis (and obviously myself) and a few others have tested these binaries. Windows, mac and linux. There are some nix builds if you are so inclined as well.

I meant, who's doing the building, but it seems like it's a Github service? I'll be back once I've read up on Actions.

[dark0dave]

@Argent77, @AngelGryph and @Incrementis (and obviously myself) and a few others have tested these binaries. Windows, mac and linux. There are some nix builds if you are so inclined as well.

I meant, who's doing the building, but it seems like it's a Github service? I'll be back once I've read up on Actions.

Ahh, sorry! Yes, its built in azure (microsoft cloud). Basically github offers free machines for open source projects.

[dark0dave]

I've add the readme to all the zips.

https://github.com/WeiDUorg/weidu/pull/263/files#diff-e426ed45842837026e10e66af23d9c7077e89eacbe6958ce7cb991130ad05adaR75-R78

Adding README-WeiDU.html to WeiDU-Linux-250.zip
zip -ur WeiDU-Linux-250.zip README-WeiDU.html
Adding README-WeiDU.html to WeiDU-Mac-250.zip
zip -ur WeiDU-Mac-250.zip README-WeiDU.html
...

[FredrikLindgren]

For release builds targeted at users, I guess the oldest available Ubuntu is best, for the widest compatibility, so 22.04. Other builds should ideally remain on ubuntu-latest, and maybe we'll catch one of the many toolchain-related build failures early.

• In release.yaml, what does the docs job do, given that the build docs step installs HeVeA and makes the readme?
• Are nightly builds going to create a tag for each build? Are the tags trimmed after some time? Otherwise (and maybe even so) it's going to be a very annoying number of tags.
• If I understand correctly, nightly builds are triggered by push activity to devel, while, as you wrote, other releases are triggered by pushing a tag, and the nightlies are flagged as pre-release. Does this mean I could not tag a Vxxx.01, which should be flagged pre-release, without triggering a normal release of the Vxxx.01 code-base that is itself not flagged as pre-release? Maybe it would be better to trigger non-pre-release builds by push activity to master, as that has been what has previously signified an allegedly stable build of WeiDU.
• Is generateReleaseNotes the thing that adds those slices of commit history to the release? Because I'm not a fan of those. The large majority of people interested in the release notes for new WeiDU builds do not understand OCaml, may not be comfortable around git history and might not be able to make sense of the commits even if they are. Ideally, there'd be a link to an up-to-date README-WeiDU-Changes.txt, but I can add that manually to the release, if need be.

I might have another round of questions left in me, but now it's enough for today.

[dark0dave]

For release builds targeted at users, I guess the oldest available Ubuntu is best, for the widest compatibility, so 22.04. Other builds should ideally remain on ubuntu-latest, and maybe we'll catch one of the many toolchain-related build failures early.

Sure no worries doing that now.

In release.yaml, what does the docs job do, given that the build docs step installs HeVeA and makes the readme?

So installing heva/tex/perl on windows is a pain (chocolattely does not support it), so I build it away from the windows VM, in a linux machine and then attach it.

Are nightly builds going to create a tag for each build? Are the tags trimmed after some time? Otherwise (and maybe even so) it's going to be a very annoying number of tags. If I understand correctly, nightly builds are triggered by push activity to devel, while, as you wrote, other releases are triggered by pushing a tag, and the nightlies are flagged as pre-release. Does this mean I could not tag a Vxxx.01, which should be flagged pre-release, without triggering a normal release of the Vxxx.01 code-base that is itself not flagged as pre-release? Maybe it would be better to trigger non-pre-release builds by push activity to master, as that has been what has previously signified an allegedly stable build of WeiDU.

Yes the idea is nightlies are triggered after a merge to devel. This lets your users experiment with recent builds. As well as testing release process.

Example:

https://github.com/The-Mod-Elephant/weidu/releases/tag/v250.01-nightly-8ebe7c1

This is a pre-release so its hidden from the other releases.

We can set it up so pushes to master trigger the nightly thats fine. I'll do that now.

And yes, when you push a tag, it does a real release.

Is generateReleaseNotes the thing that adds those slices of commit history to the release? Because I'm not a fan of those. The large majority of people interested in the release notes for new WeiDU builds do not understand OCaml, may not be comfortable around git history and might not be able to make sense of the commits even if they are. Ideally, there'd be a link to an up-to-date README-WeiDU-Changes.txt, but I can add that manually to the release, if need be.

Yes. I like to generate release notes. As a fellow developer, I do actually care about the changes you make, from commit to commit.

I avoid any manual process like the plague. Happy to disable if it makes you more comfortable.

[dark0dave]

@FredrikLindgren I've updated again, summary:

• ubuntu-latest -> ubuntu-22.04 (this is an old release) eventually we'll have to update
• Remove automatic release notes (I'd encourage you to rethink this, its helpful for me at the very least)
• Set nightlies to only be released on master

[dark0dave]

As an aside we might need a staticly compiled elkhound: The-Mod-Elephant/elkhound#16.
Dynamic linked executables are much less portable.

Ie I need to fix elkhound-> old version of ubuntu (C libs) -> update weidu

One problem at a time tho.

[FredrikLindgren]

Remove automatic release notes (I'd encourage you to rethink this, its helpful for me at the very least)

Okay, if you want them in, I'm willing to fold.

Set nightlies to only be released on master

Oh, I meant building double-oh releases from activity on master. But regardless, the whole thing was a bit of a bad idea based on a faulty premise. With the nightlies generating tags from version.ml, there should never be a need to push any tag but a double-oh one, so having release builds on tag pushes is fine.

If you don't care for it, I can change both back after I've merged (hopefully tomorrow). Good work!

[FredrikLindgren]

I can change both back after I've merged

@dark0dave, okay, turns out I forgot how you structured that bit about release notes, and the official docs only describe a snake-case variety, while the one I (perhaps incorrectly) quoted was camel-cased. Does this do the same thing, or can you post how you did your release notes?

with:
  generate_release_notes: true

[dark0dave]

I can change both back after I've merged

@dark0dave, okay, turns out I forgot how you structured that bit about release notes, and the official docs only describe a snake-case variety, while the one I (perhaps incorrectly) quoted was camel-cased. Does this do the same thing, or can you post how you did your release notes?

with:
  generateReleaseNotes: true

Hi @FredrikLindgren see above. I'll add it back in another pr.

Docs for that are here: https://github.com/ncipollo/release-action

See: #267