fix: improve beta release cicd

[MQ37]

This PR improves the pre-release CI/CD workflow. It now only runs when the PR has a beta tag (including when the tag is added without a new push). The calculation of the next beta release version is now more robust: it checks both NPM and Git tags for existing beta versions and uses the highest found, ensuring the next beta version is always unique and up-to-date.

closes #80

Notes:

it seems that there is not way to run a CICD job when a tag is removed

another alternative solution is to use github branches for beta releases that we can later remove (NPM can install from github). But for simplicity I would keep the NPM implementation

[jirispilka]

IMO, this has a lot of custom logic, and I’m not sure we really need to add it here. I think we should aim for as unified a deployment as possible across apify packages

[MQ37]

IMO, this has a lot of custom logic, and I’m not sure we really need to add it here. I think we should aim for as unified a deployment as possible across apify packages

I checked few Apify repose and it seems that this beta release workflow is not centralized and each repo handles that separately. I think developer flexibility is important and thus would also keep this decentralized, per repo.

These repos use a variant of before-beta-release.js:

• https://github.com/apify/apify-client-js/blob/master/.github/scripts/before-beta-release.js
• https://github.com/apify/apify-cli/blob/master/.github/scripts/before-beta-release.ts

These repos use on push to master model:

• https://github.com/apify/apify-sdk-js/blob/master/.github/workflows/test-and-release.yaml
• https://github.com/apify/crawlee/blob/master/.github/workflows/test-ci.yml

In the end I think this label solution is the best compromise, if you need that you can just tag and it does not run on each push to master when it's not needed. Also there is a lower chance that it breaks the versioning, last time for some reason the beta version jumped straight from stable 0.2.15 to 0.3.1-beta.0 for some reason 🤷‍♂️

[jirispilka]

Let’s ask @janbuchar or @B4nan for their opinion and review.

Purpose: We’d like to release a beta version of this package so we can include it at apify-mcp-server and test it on the staging server. We might not need this often, but having the option could be handy at times.

[MichalKalita]

I don't fully understand GitHub yaml configs, but JS part looks good.

[B4nan]

So what exactly are you trying to solve here? Do you need canary builds for PRs, or for stuff in master? Normally, we just run the canary builds for every commit to master, making this dependent on reopening a merge PR feels quite weird to me (that's what this PR is doing, right?)

The calculation of the next beta release version is now more robust: it checks both NPM and Git tags for existing beta versions and uses the highest found

This doesn't sound right to me, first of all, I really dislike the idea of git tags for every commit to master, I'd just drop those - and base the next vesion only on NPM, that is the single source of truth to me. Also, I would prefer checking the version from NPM API instead of package.json

[B4nan]

This is what we use in crawlee for detection of the next canary version number:

https://github.com/apify/crawlee/blob/e4b7f69bca6113a4622738ffd92cf8d5dfe44819/scripts/copy.ts#L68-L99

[MQ37]

So what exactly are you trying to solve here?

The Apify MCP is spread across two repos, this one and the apify-mcp-server, private one that uses the core logic from this repo. For some PRs that change specific internals we would like to publish our beta/canary release to the NPM so we can test that on staging mpc.apify.com (using the private apify-mcp-server repo) before merging PR in this repo. So I don't think it's right to automatically release canary version for each PR that does not need that.

I included the git tag logic so there is a second source of truth, since one time the beta release script cause this:

last time for some reason the beta version jumped straight from stable 0.2.15 to 0.3.1-beta.0 for some reason 🤷‍♂️

We can remove the git tag logic and add more logging so we can then trace what causes this version jump if that happens again for some reason.

[B4nan]

I see, we don't really deal with releases for unmerged PRs. I recently came across https://pkg.pr.new/, maybe you could give that a try.

Note that its not a great idea to try to come up with some ordered versioning outside of the master branch, one PR will do something, the other will do something else, they won't share the code, so better to keep their versions unrelated.

[jirispilka]

Thanks, guys. IMO, https://pkg.pr.new/ looks like exactly what we need to create an ad-hoc release for testing

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/apify/actors-mcp-server/@apify/actors-mcp-server@202

commit: cfbbb33

[MQ37]

Thank you @B4nan for recommending the https://pkg.pr.new/, it works super well 👍

[B4nan]

Great to hear that, we'll probably adopt it too in other projects if it worked well for you guys.

[jirispilka]

Really cool that it’s working!

I think it deserves a bit of documentation in the README. If it’s something others might adopt, it would be great to briefly document why we’re using it (what problem it solves) and how it works.

[MQ37]

Really cool that it’s working!

I think it deserves a bit of documentation in the README. If it’s something others might adopt, it would be great to briefly document why we’re using it (what problem it solves) and how it works.

Makes sense, documented that in "Canary releases" section of "Development" README main heading 👍

[jirispilka]

👍🏻