Create release generation CI/CD

[baetheus]

trafficstars

On push/merge of a commit containing the release: conventional commit message, generate a zip file or some other release artifact that is added to the github releases list.

Overlaps with #39 .

[pixeleet]

Would love to fix this, what versioning strategy should we adapt? (e.g. semantic-release style vs. bigger releases?) Is deno the only target?

[baetheus]

I'm partial to semver. Deno is definitely the only target.

[pixeleet]

Are you absolutely opposed to supporting Node?

[baetheus]

I'm not personally interested in supporting Node but I'm also not dead set against it. I figure if you're going to use Node it's more likely that you'll go with fp-ts instead of fun. That said, if you want to add support for Node I'm willing to support your efforts. To that end I have a few requirements.

1. I personally use raw links such as this when trying out new features and throwing together small scripts. Support for Node cannot rely on altering the ES module imports of any source code directly. Basically, the fun modules have to be directly usable when running Deno.
2. The library will need to be released to the nll org in npm like @nll/datum is. This will require me setting up a publish key for use with this lib. I'm fine with this but I'll be traveling in Spain for the month of February so I may not be as available as I am right now.
3. Historically, I've used standard-version for tracking semver via git commits. If possible, I'd like to avoid having node as a build dependency of this so perhaps we could go with a tool like (but not necessarily exactly) version that does something similar.

How does that sound?

[pixeleet]

Sounds like a plan! I wanted to use something similar to semantic-release but it's just all to much with the plugins and whatnot. Node is not a definite goal, but if I'm gonna hack on this lib, I might eventually want to port some stuff in Node to it. So I was curious if that would be something you're opposed to.

I'm thinking about essentially writing a tiny deno script to do a bit of what semantic-release would do, I'll ping the PR to the issue once I have something. Cheers!

[pixeleet]

I have written up a small library called semantic-release-tooling that would enable pretty much the same feature set as semantic-release but with a smaller footprint. Would you be interested in a pairing session to get it out the door?

[baetheus]

That sounds great. I'm going to be a bit busy until around Wednesday of next week (2022/03/16) but could probably make time after that from 1000 to 1600 PST on Wednesday, Thursday, Friday, Saturday, or Sunday. If any of those times work for you shoot me an email at [email protected] and we'll get it set up. I'll put together a loose agenda before the meeting and post it here for you to add/comment on so we don't get too off course.

[pixeleet]

There should be a deno (or a makefile target) task

e.g.:

{
  "tasks": {
    "version": "srt"
  }
}

SRT has two versioning modes today:

• Once [default] (Takes highest release-type from parsing all commit messages since last tagged version)
• Every (Bump each for every commit that we can parse to a meaningful release-type since last versioned commit)

Based on the mapping that is currently hardcoded in the git module currently, we'll map commit-types to release-types. (This is slated to be extracted into configuration later on.)

const bumpByCommitType: Record<Bump, CommitType[]> = {
  noop: [
    CommitType.Build,
    CommitType.CI,
    CommitType.Chore,
    CommitType.Docs,
    CommitType.Perf,
    CommitType.Release,
    CommitType.Revert,
    CommitType.Style,
    CommitType.Test,
    CommitType.Skip,
    CommitType.Unknown,
  ],
  pre: [],
  premajor: [],
  preminor: [],
  prepatch: [],
  prerelease: [],
  patch: [CommitType.Fix, CommitType.Refactor],
  minor: [CommitType.Feat, CommitType.Merge],
  major: [CommitType.Breaking],
};

Once (example)

➜  fun git:(v2) ./Users/davidpeter/Workspace/kittenpilez/semantic-release-tooling/out/srt-aarch64-apple-darwin
2022-03-19T14:09:31+01:00 ℹ Runtime: git
2022-03-19T14:09:31+01:00 ℹ Reading current version...
2022-03-19T14:09:31+01:00 ℹ Current version: 1.0.0
2022-03-19T14:09:31+01:00 ℹ Parsing logs
2022-03-19T14:09:31+01:00 ℹ Next version: 1.0.1
2022-03-19T14:09:31+01:00 ℹ Version set to:  1.0.1

Every (example)

➜  fun git:(v2) /Users/davidpeter/Workspace/kittenpilez/semantic-release-tooling/out/srt-aarch64-apple-darwin -S every
2022-03-19T15:14:41+01:00 ℹ Reading current version...
2022-03-19T15:14:41+01:00 ℹ Current version: 1.0.0
2022-03-19T15:14:41+01:00 ℹ Getting formatted logs from git.
2022-03-19T15:14:41+01:00 ℹ Parsing logs
2022-03-19T15:14:41+01:00 ℹ Next version: 1.15.0

Now that we have a version number, we could use it to

• tag current commit with it
• release a new version

What the release process would entail besides outputting a bundle? e.g.: mkdir -p out/deno && deno bundle mod.ts > out/deno/lib.js

[baetheus]

In #37 I outlined the reasons I have for continuing to version manually.