Update contributing guide

[hynek]

Here's a PR @webknjaz – I even made it out of sync with main. ;)

[webknjaz]

🎉

[webknjaz]

@hynek drop the requirement for the branches to be rebased.

[hynek]

@hynek drop the requirement for the branches to be rebased.

what exactly does that mean? I've switched off the need update 🤔:

Is it linear history?

[hynek]

linear history off doesn't work either

[webknjaz]

what exactly does that mean? I've switched off the need update 🤔:

Should be this one. Could you make a full page screenshot? Do you have multiple branch protection rules? What do they look like?

[webknjaz]

This is weird:

Did you accidentally select the "Lock" checkbox?

[hynek]

This is no productive workflow, I've given you admin privileges please look yourself. ;)

[hynek]

but yeah lock branch was always on, so nobody pushes directly.

[webknjaz]

This is no productive workflow, I've given you admin privileges please look yourself. ;)

Okay, will do :)

[webknjaz]

but yeah lock branch was always on, so nobody pushes directly.

That doesn't sound right. It's supposed to block virtually any updates, unless you merge bypassing the restrictions..

[webknjaz]

@hynek so yeah, I think Lock branch is at fault. What you want should already be covered by Require a pull request before merging, except you added yourself Allow specified actors to bypass required pull requests which may cause a confusing impression that it might not work.

I've unchecked Lock branch and everything should work now.
Moreover, I inspected the audit log and found out that you enabled this checkbox 3 days ago. See for yourself: https://github.com/organizations/python-attrs/settings/audit-log?q=+action%3Aprotected_branch.update_lock_branch_enforcement_level — you added the lock, I removed it and there's no other changes related to this toggle in the log. If it was in place for longer, nobody would be able to update main (i.e. merge PRs) and it'd be noticed much sooner.

[webknjaz]

@hynek I'll leave clicking "Merge when ready" to you so you could experience how this works.

[hynek]

stares excitedly

[hynek]

It didn't trigger the pypi workflow but I think that's OK. I've removed the requirement.

[webknjaz]

@hynek ah, this https://github.com/python-attrs/attrs/actions/runs/6694666592? It still happened post-merge, on push. I suppose you may want to update the event triggers there to do what you want. Such disconnect between workflows is one of the reasons I've started migrating towards a “main” workflow with all the events that ties together reusable “modules” that don't have other event triggers except for workflow_call.

[hynek]

I've been doing something different lately which is similar to your sdist workflow but goes a step further: https://github.com/hynek/svcs/blob/84726ff72eb080f6464e1ec8f9d25912eb3230a8/.github/workflows/ci.yml#L21-L66

I'll move attrs to it when… I have time 🤡

[webknjaz]

@hynek it's actually pretty much the same AFAICS

[webknjaz]

@hynek did you replace the action with a tar invocation because you also wanted a wheel? I like to download both wheel and sdist. Use sdist instead of a Git checkout and pass the wheel to --installpkg. Did you not like having to download the GHA artifact twice? If yes, I think it might be reasonable to factor that into my action's API and maybe expose the wheel from the same artifact additionally. WDYT?

[hynek]

Yeah the wheel was the reason. Given I want to use my own builder/linter it didn't give me much if anything. I don't remember the exact details anymore, but I'm not sure what I'd need an opaque action for? Like what could I save compared to status quo? it's just a download + un-tar. 🤔

But yes, "pre-built wheels for code, everything else from sdist" is the way to go IMHO. Nothing gets closer to what we ship so I really like it.