Bumps GH actions to pre-releases

[evgeni]

Package manage/ecosystem

github_actions

Manifest contents prior to update

Updated dependency

What you expected to see, versus what you actually saw

Images of the diff or a link to the PR, issue or logs

This has been already reported in #1461 (comment), but I felt like an separate issue makes sense for both tracking the state and finding it easier.

dependabot currently updates GitHub actions to pre-releases, which seems counter-intuitive. Having that behavior hidden behind a configuration flag might be useful, but I think the default should be to only update to full releases.

Example PR: theforeman/forklift#1181

[evgeni]

cc @ekohl

[peaceiris]

Again from #1461 (comment)

It will be nice to detect pre-release or beta tag and do not bump it.

Check a GitHub release type

The actions/setup-node@v2.0.0 is a beta version (pre-release). We need a useful filter for not bumping it.

Check a tag format

Semantic Versioning 2.0.0 has a format for a beta release like 1.0.0-beta, 2.0.0-rc.2, and v3.7.0-1.

It is useful:

• Not to create a pull-request for those releases OR
• User can set up with their .github/dependabot.yml wether accepting beta release it, or not.

[abbylentz]

Is there a way they can continue to use Dependabot without getting pre-release version updates and without ignoring "minor" versions?

[deivid-rodriguez]

My understanding is that we currently rely exclusively on git tags and their names to figure out what update to propose. We'd need to teach Dependabot about prereleases with "release-like" names by using the releases API.

[jeffwidman]

While I love the Releases UI and use it routinely in my open source projects, I'm much more a fan of communicating the non-stable versions directly in the version number / tag, and not indirectly through a metadata API like the releases API. For example, we recently added support to Dependabot for fetching/updating actions hosted at custom locations not necessarily GitHub... so the releases API wouldn't work then...

Also, IIRC the releases API "pre-release" designation isn't immutable... it can be added/removed after the version is released. So it puts us in a non-deterministic state... what if when Dependabot checked it was a pre-release, but then right after the author removes that designation?

FWIW, Actions recommends a versioning scheme that embeds indications of beta / pre-release into the tag itself:

Major versions can be initially released with a beta tag to indicate their status, for example, v2-beta. The -beta tag can then be removed when ready.

We may want to sync internally with the Actions team to ask them to tighten that recommendation to not only major versions, but also any versions with alpha/beta in the suffix treat as pre-release. I don't think it can be just any suffix as suffixes may sometimes be useful to communicate other information such as OS / hardware platform compatibility, etc.

If we don't already, we probably should add a UT in dependabot-core checking that we honor the -beta tag: ... this would be an easy thing for us to treat as non-stable vs stable when upgrading.

[alexon1234]

Hey,

I'm facing the same problem with a pre-release package we have in python using pip. In our case, we are using the format X.X.X.devX.

Does anyone has achieve to add an ignore setting for this case? We are publishing a pre-release, so we do dogfooding of our own CLI before realizing to the our customers and this is a real pain as our customers are getting notified by the Dependbot about a new pre-release version.

[deivid-rodriguez]

I think that's most likely because of #6300. We don't currently deal well with Python prereleases.

[Th3S4mur41]

It would be nice to follow a similar concept to NPM and be able to release a new (major) version as stable, without marking it as latest and so not triggering the dependabot update.

The default setting from semantic-release cover exactly this use case with the next and next-major branches...

Something similar could be achieved without switching to the release API though, simply by adding a latest tag the same way we add the major version tags.

This way, workflows could be updated manually to newer stable versions and wouldn't need to be updated again, once the version is marked as latest. And workflows would be updated automatically as soon as the latest tag is set and it is safe to upgrade.