GitHub's editor is useful for simple fixes, (formatting, markdown, typos,) but Codespaces seems extremely useful in building a reproducible dev environment for more complex packages / projects, including build tooling!

Yes but OP was talking about simple fixes in the first place

Even simple fixes often need to be run/tested before a PR can be put up with confidence.

a one minute change isn't ran or tested, almost by definition.

If you could have a fully-functional dev environment with pre-installed dependencies in 10s and the package takes 48 seconds to build and test, then you could.

I'm aware of several places in my team's codebase where you can change a couple of characters and break the entire company if you didn't test the change.

Wrong

There's a very big difference between editing a file in a textbox and editing a file in an IDE pre-configured to have all the correct dependencies, extensions, build&test scripts, intellisense, etc.

Of course there is! But if it's literally one line...

The set of single line changes I'd be comfortable making with full IDE support is much larger than the set of one line changes I'd be comfortable making in a text box.

I feel like even with one-line fixes, having the tests run before committing (to see the CI/CD results instead) would give people a lot more confidence in making those changes.

Personally speaking, I'd be worried that I end up making 15 commits to get everything right and the history in that PR would be slightly embarrassing. Having the live linting, intellisense and tests makes pushing a single commit a lot easier.

That was already possible with Travis CI though. Not sure how the situation is now, are they still up and running?

The difference is habbit.

We are not in the habbit of doing this now.

This change may change that habbit and encourage a new one.

Im not saying it will, but its naive to brush literally every suggestion off because you can already do something similar.

At least think it through before making a judgement on a new idea.

Yeah, where this gets really interesting is in the integration with the project's build system, CI, and test environments.

I'm envisioning a project with a full automated build and test suite with an on-demand staging environment for each change (the k8s docs project does this, at least it did the last time I chucked a typo PR over the wall).

With proper integration to the editor you could have an extremely slick dev environment instantly available for any casual passerby. Once implemented, this would greatly simplify maintainers' lives as well!

The edit button is perfect for fixing typos; I don't think I've ever even used it for any other purpose. Tidying-up typos up as you're passing through is a small way in which anyone can help contribute! It's like picking up pieces of trash as you're strolling through a park.

a bit of a noob question. I'd love to be able to tweak code on the spot. Like I'm showing something to my boss and he wants something quickly adjusted, I write a couple lines, commit and then with Github Actions I get back an updated executable immediately

But I feel like things are set up explicitly to not work this way. Maybe I'm doing something wrong but can you trigger a rebuild of a prerelease?

It seems you need to setup a new tag and a new release version to ever get a rebuild. There are explicitly no official Actions for updating releases. A new release for a one line change seems a bit crazy (and you'll get a huge clutter of releases which is confusing for users)

I tried to ask and was told it's maybe possible if you write an action yourself .. yikes https://github.community/t5/GitHub-Actions/What-s-the-canoni...

You can set up your actions to build an executable for each commit on the master branch, it will be available as an artifact in the actions tab. This is useful if you want to test your built code.

Generally speaking, you shouldn't modify existing releases, since somebody may have downloaded them and he will have no way of knowing you have improved them.

I guess you're right. That this is the expected workflow. The way the UI by default dumps Prereleases and Releases together (with very small faint font to distinguish them) in the same tab called "Releases" is an issue so I sorta understand why you feel it'd be confusing. The UI is no good, but this is not an insurmountable problem

It's true you can have a latest artifact.. I will try using that - but I can't email a colleague and tell him/her to download an artifact. There is no "latest build action artifact" page and there is so much extraneous information that if they've never used github you'd need to attach an explanation of where to click.

I didn't feel my use-case was particularly unusual, but I guess it's doesn't fit Github's model.

You still have to fork

Because implementing a shadow fork is sooo hard.

You must be fun at parties

I think you missed the part where i was being positive to new ideas and not just being a pointless debbie downer.