[Suggestion] change test-and-release to NOT deploy alpha releases

[mcm1957]

I would suggest to add && ! contains(github.ref, '-alpha')
to the standard test-and-release.yml workflow like it is shown below.

This change would block -alpha releases to be deployed to npm.

    # Trigger this step only when a commit on any branch is tagged with a version number
    if: |
      contains(github.event.head_commit.message, '[skip ci]') == false &&
      github.event_name == 'push' &&
      startsWith(github.ref, 'refs/tags/v') &&
      ! contains(github.ref, '-alpha')

Currently ALL releases are deployed to npm (when using stadard test-and-release.yml workflow) which is not alway desired as every release deployed to npm is immidiatly listed at lates repository. This changes provides the possibility to generate alpha release at github which are not deployed at npm and hance not delivered via latest.

Please evaluate suggestion.
I can of course provide an PR if suggestion is accepted.

[AlCalzone]

One problem I have with that: we apparently cannot expect devs to read the comments explaining how to set up the npm token, although the dev readme mentions this and it's written in plain english.

This change would be far more subtle, and possibly unexpected. After all when you end up there, you did run the release script, which has a pretty clear intention: release the adapter.

Maybe this limitation belongs in the repository generation script instead?

[mcm1957]

Well,

The idea is to generate a release - an ALPHA release without deploying it to latest. Currently - during development with an extreme small number of contributors you cannot creat a test release without deploying it to latest. So you end up with either no release numbering during test and fix phase or with sending the alpha releases to the complet latest world.

The releasescript can handle / generate alpha and beta releases. But they are pretty useless in regard to limiting distribution.

Maybe we have different interpretions of release script.
You see its purpose in releasing a new version.
I see the prurpose in CREATING (tagging incl. setting lables, translations, ...) of a new version and (optionally) releasing the version.

Whether this change would be unexpected - well I do not know. Do you have any idea how many users ever used -alpha/beta/... releases ?

What do you mean with repository generation script? I do not associate anything to this term.

[AlCalzone]

What do you mean with repository generation script? I do not associate anything to this term.

I mean the script that generates the latest repository, which is this JSON file containing the versions:
http://repo.iobroker.live/sources-dist-latest.json and which ioBroker uses to know which versions to install.
It seems that this script simply takes the latest dist-tag:
https://github.com/ioBroker/ioBroker.repositories/blob/432a081ab919872bd3ecccddc9385d8640314dc7/lib/scripts.js#L135

I suppose we could change the deploy action to set a different npm dist-tag when publishing a prerelease version:
https://github.com/ioBroker/testing-action-deploy/blob/2bad1a2197b9d3cb89061d34e27cab7cc9b12c61/action.yml#L100

That way the script wouldn't "see" alphas or betas.

[AlCalzone]

Maybe we have different interpretions of release script.

By release script we typically refer to https://github.com/AlCalzone/release-script/, which runs on your computer, prepares the release commit, tags it and pushes it.

On Github, the test-and-deploy workflow takes over (which is what you suggest editing). Part of that is the deploy action, which actually creates the releases and is responsible for putting the release on npm.

And after that, the aforementioned repository script scrapes npm and generates the ioBroker repository from it.

[mcm1957]

What do you mean with repository generation script? I do not associate anything to this term.

I mean the script that generates the latest repository, which is this JSON file containing the versions: http://repo.iobroker.live/sources-dist-latest.json and which ioBroker uses to know which versions to install. It seems that this script simply takes the latest dist-tag: https://github.com/ioBroker/ioBroker.repositories/blob/432a081ab919872bd3ecccddc9385d8640314dc7/lib/scripts.js#L135

I suppose we could change the deploy action to set a different npm dist-tag when publishing a prerelease version: https://github.com/ioBroker/testing-action-deploy/blob/2bad1a2197b9d3cb89061d34e27cab7cc9b12c61/action.yml#L100

That way the script wouldn't "see" alphas or betas.

Your suggestion looks excellent in my opinnion. It's not my goal to block npm deploy itself for alpha releases but to block at least alpha release (or eventually beta, gamma, ... too :-) ) from delivery by ölates repository. So any solution which will do the deploy but block the listing (and delivery) of the alpha releases via latest repo will fully satisfy my suggestion.

In addition - are you sure, that repositories/lib/scripts will do the upating of repo.iobroker.live?

I've added a suggestion to add a possibility to (temporary) block latest updates for an adapter (ioBroker/ioBroker.repositories#2345) which I would discuss with Info after his holidays. Eventually this could be implemented (or dropped) together.

And I did some investigation on ioBroker/ioBroker.repositories#2097 which seems to be caused by an incorrect date delivered by latest repo. If the obove script is creating this info I could try to locate the prpoblem there. (Of course I would not change anything without confirm /review at such a critical place)

[AlCalzone]

Solved in ioBroker/testing-action-deploy@5a8157f