Github Action broken (unable to find version "stable")

[mlissner]

I'm pretty sure this isn't my fault, but our Github Action just started failing with the following message:

Error: Unable to resolve action psf/black@stable, unable to find version stable

You can see this happening here: https://github.com/freelawproject/eyecite/runs/2248542521?check_suite_focus=true.

I'm guessing that this is related to dropping the stable version or something like that, but I expect it will affect a lot of folks that use the action since the docs recommend configuring it this way.

[ichard26]

We're in the process of getting ready for a release so yeah? I haven't been involved in this effort so I don't know the details. Why would the stable branch be deleted? IDK, probably a mistake from the cleaning up they've been doing.

cc @ambv @cooperlees

[folksgl]

We're experiencing the exact same issue @mlissner. Not isolated to you or your project. See https://github.com/folksgl/identity-give-usps/runs/2248887438?check_suite_focus=true

[sh-cho]

stable release(or branch) is removed?

[askb]

Has anything changed with the 'stable' branch? Most of our jobs on the infra seem to be impacted with this.

05:07:37 [INFO] Initializing environment for https://github.com/ambv/black.
05:07:38 An unexpected error has occurred: CalledProcessError: command: ('/usr/bin/git', 'checkout', 'stable')
05:07:38 return code: 1
05:07:38 expected return code: 0
05:07:38 stdout: (none)
05:07:38 stderr:
05:07:38     error: pathspec 'stable' did not match any file(s) known to git

[sh-cho]

Just workarounds for those who wonder

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/psf/black
    rev: 20.8b1  # change this
    hooks:
      - id: black
        language_version: python3

# .github/workflows/black.yaml
name: Lint

on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-python@v2
      - uses: psf/black@20.8b1  # change this

[algobytewise]

Same issue at https://github.com/TheAlgorithms/Python. @sh-cho's fix seems to work.

[sdodsley]

So is the stable branch coming back?
There doesn't seem to be a simple answer here...
I don't want to change my workflow to use a beta release as suggested above.

[ichard26]

@sdodsley The core team wants to bring it back ASAP, but no one who has the right perms has done it yet ...

I don't have write permissions or else I probably would've done it by now. I'm sorry.

[cubranic]

Despite the names, “stable” just installed the 20.8b1.

…

On Apr 2, 2021, at 11:12 AM, Richard Si ***@***.***> wrote:  [CAUTION: Non-UBC Email] @sdodsley The core team wants to bring it back ASAP, but no one who has the right perms has done it yet ... I don't have write permissions or else I probably would've done it by now. I'm sorry. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[sdodsley]

@cubranic that may be so, but I do not want to keep having to check the black repo for new releases, that is why stable is so useful.

[askb]

@cubranic that may be so, but I do not want to keep having to check the black repo for new releases, that is why stable is so useful.

That's what I thought 'stable' was for, surprised it has been removed.

[ghost]

It seems resolved for my project somehow.

Repository: https://github.com/simaki/fracdiff
GitHub Actions Log: https://github.com/simaki/fracdiff/runs/2283915996?check_suite_focus=true

[ichard26]

Yeah, now there's a stable tag pointing to the commit that ended up being the 20.8b1 version, but there's no stable branch. So psf/black@stable pretty much translates to psf/black@20.8b1. I'll see if I can resolve this mess before the stable reference no longer points to the latest published version, no promises though.

[cooperlees]

What does a branch give us? When we do the next release don’t we just move the stable tag and it works for everything people are using it for? What am I missing? What is the advantage of a branch? The only reason I’d imagine we want a branch if we wanted to cherry pick a fix on to a released version. But we can do that if ever needed. I think most black developers agree that we will just forward fix.

I hope to one day get more consistent releases tho.

[jerinpetergeorge]

Why we aren't using psf/black@master 🤔

[fizyk]

@jerinpetergeorge I suppose you can, but that's development branch, so you'll have a rolling release with all it's consequences.

[ichard26]

@cooperlees First of all I want to apologize for being so damn unclear during our IRC conversation. If it's any explanation (not an excuse!) that day in general was pretty crappy so my tolerances were unusually low. Anyway with a clearer mind, let me explain myself:

The main issue is that tags are by design extremely hard to mutate, when the stable tag is changed to point to another commit local git fetches won't get the updated tag without some extra work. This is actually why the stable tag was changed to a branch (see GH-760). The git docs on this topic are also worth a read (although I should make it clear that I don't agree the language used).

There also might be some issues with ReadTheDocs not triggering a build automatically when the stable tag is moved, but I haven't confirmed that, just noticed how the stable reference was changed to point a different commit yet RtD didn't notice (it could just be webhook weirdness).

The only reason I’d imagine we want a branch if we wanted to cherry pick a fix on to a released version.

Personally I'd discourage this as much as possible (if not disallow it straight up) regardless of whether the stable reference is a tag or branch.

edit: there's also an issue with the stable tag being marked as a release in the GitHub UI which isn't ideal (I wonder whether the GitHub release will update if the tag is updated).

[kthy]

Could you perhaps pin this issue, please? I've always used specific releases, so my spidey senses tingled when I saw a stable tag suddenly appear without explanation and worried whether it was legit or package poisoning.

[ferndot]

It has been a while. Is the branch coming back?

[JelleZijlstra]

We have a stable branch again now.

[aviyadeveloper]

Has this been somehow renewed? @JelleZijlstra

Run psf/black@stable
  with:
    options: --check --diff
    src: .
/usr/local/bin/python3: can't open file '/home/runner/work/_actions/psf/black/stable/action/main.py': [Errno 2] No such file or directory
Error: Process completed with exit code 2.

This is failing since yesterday.

changing the job to use:
- uses: psf/black@20.8b1

also solves it.

[felix-hilden]

Reading the references a bit and reflecting on the repository:

• We moved our stable tag recently to match two new releases (stable)
• We do not have a branch called "stable" (branches)
• Moving tags is bad (Please don't move tags #760) (this is new information for me as well 😅) and pre-commit assumes tags to stay consistent

So yeah, I agree that this should be reopened, and the stable branch should be introduced once more.

[aviyadeveloper]

@felix-hilden @JelleZijlstra
Actually using version 21.6b0 results in the same error as i mentioned earlier.

So it actually might be a problem with that specific version rather than the @stable tag/branch which leads to the proper newest stable release.

#2335

[felix-hilden]

* Moving tags is bad and pre-commit assumes tags to stay consistent

I think I've misunderstood something here: surely a moving branch is as bad for caching as a moving tag is. So maybe the situation is a bit more complicated.

[folksgl]

* Moving tags is bad and pre-commit assumes tags to stay consistent

I think I've misunderstood something here: surely a moving branch is as bad for caching as a moving tag is. So maybe the situation is a bit more complicated.

To be clear... moving tags is bad for pre-commit. Because pre-commit is assuming that tags are an immutable point in time in a repositories history (not a bad assumption, but it's just not true right now for Black).

Pre-commit will cache the code associated with a tag and never again check to see if that code changed. What I think people would like to be able to do, is to set up a .pre-commit-config.yaml and never have to worry about it again (because hey... that would be nice). What I think is far more realistic is that there will be "stable" something for Black, and a "stable" for users projects. i.e. right now, my project is using black vX.Y.Z. Then, occasionally, users will have to pre-commit autoupdate to update their rev field in the .pre-commit-config.yaml to the latest Black tag.

That however introduces it's own problems since the "latest" black tag isn't always a version that's considered stable. So users will likely have to either manually edit their pre-commit config files or just be OK with having a beta release should they choose to pre-commit autoupdate.

[ichard26]

OK,

First of all, whether stable is a branch or tag shouldn't matter here. This isn't pre-commit but GitHub Actions which AFAIK doesn't cache actions (although all of the talk about tag / branches being problematic with pre-commit are 100% valid). Note that uses: psf/black@stable in a workflow means that the latest version of the action will be used, but not necessarily the latest of Black as well (well versions below and maybe including 21.5b2 always downloaded the latest version of black to use). Newer versions of the official black action supports the version input telling the action to use a specific version of black (I would strongly recommend pinning black to avoid sudden CI failures when we make a new release) regardless what version of the action is used. Although I think in hind-sight, recommending pinning for most (if not all) integrations sounds like a better idea.

Second thing, sadly I can't reproduce:

https://github.com/ichard26/testblackaction/actions/runs/939706114
https://github.com/ichard26/testblackaction/runs/2830604285

I will take responsibility here since I was the last person to make significant changes to how the action works, but to be honest, I don't understand why or how this is failing.

PS. I say that GitHub Actions doesn't cache Actions, but I genuinely don't really know

[folksgl]

You're correct that branch v tag shouldn't matter. But with the pre-commit configuration used within github actions (where yes, things aren't cached), users are going to see their workflows fail because the version github actions pulls from black is eventually not going to match their locally cached version of stable that they validated against (which likely should have been pinned) at whenever they ran the tool.

Perhaps if pre-commit is going to be listed on the page for version-control integrations it should be updated to have the most recent "stable" release of black explicitly as opposed to its current form. So changing:
rev: stable # Replace by any tag/version: https://github.com/psf/black/tags to
rev: vX.Y.Z # Replace by any tag/version: https://github.com/psf/black/tags

pre-commit works by caching a version that the user specified, and updating when the user tells it that it's time to update. I think having the vcs integration page list stable leads users to believe they'll always have the latest stable version, instead of whatever version was considered stable when they ran the pre-commit install

Version pinning solves this issue and I agree that nearly all projects should be pinning their version of Black just like any other dependency. But the current recommendation of rev: stable obfuscates the fact that you did actually just pin to whatever version stable was at the time of install.

[ichard26]

Thanks for explaining but I do happen to roughly know how pre-commit works and how bad the recommendation of rev: stable is, I'd certainly accept a suggestion to at least get rid of references to stable for pre-commit (and GHA as well).

It's my understanding here that this issue is about GHA and the official black action we provide, not GHA + pre-commit configured to use black. Our recommendations of using black with pre-commit are problematic in its own way, but I'd argue it's noise to the fact the official action is failing (I can open a new issue about pre-commit later). I'm sorry if I'm mistaken.

[pfheatwole]

FWIW, force pushing a modified stable tag breaks other tools such as vim-plug. See #2503

[Shivansh-007]

This can be closed, we have got the stable tag now.