spectral: Auto-created releases don't include all artifacts

In the last month or so it appears some work has been going on 🎉 but as part of the CI/CD process, stoplight-bot is creating a release for each tag 😦 - this @stoplight/spectral-ruleset-migrator-v1.3.0 release is an example.

These releases don’t include the executables or other artifacts like in a fully versioned release - it’s just a source snapshot. While this isn’t a showstopper, it really breaks the interface for https://github.com/stoplightio/spectral/releases/latest and https://api.github.com/repos/stoplightio/spectral/releases/latest, which scripts and build tasks can use to download the latest release of the tooling.

Is there a way to either…

Stop releasing these @stoplight/* tags (and delete the existing incomplete “releases” so they don’t show up anymore)? OR
Make sure these releases also include all of the executables and everything so the latest release actually has a complete latest release?

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 26 (26 by maintainers)

Most upvoted comments

Sweet! I will unpin in our build and give it a shot on Monday!

tillig on Aug 28, 2021

Heyo! Just wanted to follow-up - I’m going to get this done tomorrow. I’ve done some research around semantic-release, and I’ll need to make a few minor changes in our config, but we should be good.

P0lip on Aug 27, 2021

I think that’s the trouble with having a tool and libraries - GitHub releases is a great solution to handle updates… for the binaries or the standalone tool.

True, I agree with you.

Perhaps splitting the CLI part and binaries off to a separate repo and releasing from there? This repo could still have the per-library release schedule and the binaries/CLI could be, say, periodic or whatever like ESLint does it.

I’m afraid this won’t be possible for other reasons than engineering-related.

Out of curiosity - you mentioned npm is the source of truth for Node.js updates and many packages don’t even use GH releases. It seems like that might be a reason to dedicate the GH releases to the tool part of things. Who is the intended consumer of these non-semver releases? Is it expected library consumers would come in there to see changes? Something else? Could you generate a GitHub Pages markdown page on commit with the changelog rather than issuing a release?

I really like this idea. Honestly, we used to maintain our own changelog.md anyway, therefore it wouldn’t change much if we had these automated changelogs or not. I believe I’ll go down this path - not going to happen today or tomorrow, but hopefully next week assuming I won’t need to rewrite the whole release script.

P0lip on Aug 19, 2021