search

dependabot / dependabot-core

🤖 Dependabot's core logic for creating update PRs.
https://docs.github.com/en/code-security/dependabot
MIT License
4.75k stars 1.03k forks source link

Bumps GH actions to pre-releases #2303

Open evgeni opened 4 years ago

evgeni commented 4 years ago

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 https://github.com/dependabot/dependabot-core/issues/1461#issuecomment-638181262, 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: https://github.com/theforeman/forklift/pull/1181

evgeni commented 4 years ago

cc @ekohl

peaceiris commented 4 years ago

Again from https://github.com/dependabot/dependabot-core/issues/1461#issuecomment-638181262

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:

Screen Shot 2020-07-22 at 13 10 17
abbylentz commented 1 year ago

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

deivid-rodriguez commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

I think that's most likely because of https://github.com/dependabot/dependabot-core/issues/6300. We don't currently deal well with Python prereleases.

Th3S4mur41 commented 11 months ago

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.