Add GitHub Codespaces integration to allow for easy onboarding of future generations of contributors #21068

practicalswift commented at 6:34 PM on February 2, 2021: contributor

Add GitHub Codespaces integration.

This PR makes it easier to onboard new contributors to Bitcoin Core by providing a web based development environment that is trivial to setup.

By starting a GitHub Codespace instance using this integration in this PR a developer gets access to a configured C++ IDE with typical IDE features such as working code completion, refactoring tools (rename function, etc.), etc.

In addition the IDE environment a Linux environment is spun up by GitHub Codespaces. This Linux environment is accessible via a web based terminal. A new developer can run say make && src/bitcoind -regtest in the web based terminal after making a small change and see the results of his/her work immediately while staying in the browser. Instant gratification! :)

GitHub Codespaces is not magic. It is simply the combination of three things:

A web based editor/IDE
A web based terminal
Access to a private Linux instance which is accessible via said web based terminal

How to test this PR

Request access to GitHub Codespaces which is currently in beta:

Go to https://github.com/features/codespaces and apply: applications seem to be approved automatically within a day or two AFAICT.

Once you have beta access to GitHub Codespaces:

Go to https://github.com/codespaces.
Click "Create your first codespace".
You can now either enter a repo/branch you control which contains the commit from this PR, or you can use my demo repo bitcoin-codespaces/bitcoin and the branch master. I've setup the demo repo to allow for easy testing of this PR: see this diff for the changes between bitcoin-codespaces:master and bitcoin:master. If/when this PR is merged bitcoin/bitcoin will be the repo to use of course :)
Click "Create codespace".
Wait until the initial setup finishes: this will take a couple of minutes on first run.
Enjoy your new web based IDE! Try making some small change, type make && src/bitcoind -regtest in the web based terminal and enjoy your work! :)

Add GitHub Codespaces integration 81d5df2710

luke-jr commented at 6:38 PM on February 2, 2021: member

Concept NACK

We have plenty of PRs, and too little code review. We shouldn't encourage code review to be done using trusted third-party middleware.

practicalswift commented at 6:39 PM on February 2, 2021: contributor

@luke-jr I cannot parse. What are you trying to say?

luke-jr commented at 6:45 PM on February 2, 2021: member

I am saying people should review code (at least) locally, not using web-based third parties which could display one thing and hash another.

laanwj commented at 6:49 PM on February 2, 2021: member

Not sure about this. If it's anything to go by, contributions made through the github web interface tend to be low quality and give maintainers extra work in explaining how e..g. squashing commits works. I'm somewhat afraid this will have a similar effect.

I also don't really want to increase our dependency on github-specific flows.

I am saying people should review code (at least) locally, not using web-based third parties which could display one thing and hash another.

I don't think this is about reviewing changes, but about making them.

practicalswift commented at 7:09 PM on February 2, 2021: contributor

@luke-jr

I am saying people should review code (at least) locally, not using web-based third parties which could display one thing and hash another.

How is that relevant in the context of this PR? GitHub Codespaces is not a review tool.

practicalswift commented at 7:22 PM on February 2, 2021: contributor

@laanwj

If it's anything to go by, contributions made through the github web interface tend to be low quality and give maintainers extra work in explaining how e..g. squashing commits works. I'm somewhat afraid this will have a similar effect.

GitHub Codespaces is not magic. It is simply the combination of three things:

A web based editor/IDE
A web based terminal
Access to a private Linux instance which is accessible via said web based terminal

Note that you'll still have to understand how to use git, make, etc in order to contribute.

Given this clarification, are you still skeptical to this?

If so, help me understand why: is it the "accessible via the browser" part that makes you think that this will risk make things "too easy"? :)

laanwj commented at 7:33 PM on February 2, 2021: member

Given this clarification, are you still skeptical to this?

Well, that does sound somewhat better, but it's true that I am very skeptical of anything through-the-browser and cloud services in general. It's always "someone else's computer" and not really under your control. Which is not that great for a project with high security requirements.

All in all I think this can be great for some kind of projects (e.g. frontend ones), the have a fast feedback cycle, but I'm still skeptical this is a good idea for this project.

jonatack commented at 8:06 PM on February 2, 2021: member

Thanks @practicalswift, requested access to try it. I agree that it seems good neither for review, nor for contributing, and that we don't want to increase dependence on GitHub-specific workflows or lock-in which this GitHub feature aims to hook us into, but will try it out.

fanquake commented at 2:48 AM on February 3, 2021: member

As mentioned by @laanwj, the contributions we receive through the web interface are notoriously low quality. You can generally tell the web UI has been used by the default "Update filename.xyz" commit messages, and stack of "fix it" commits. I actually opened a related issue in the maintainer feedback repo; it would be great if we could force contributors to write meaningful commit messages, rather than just smashing green buttons in the UI until they open a PR (it might even help cull some of the spam).

commit_messages

When the web editor has been used, obviously the user hasn't even checked that their code compiles, let alone run the unit or functional tests, or actually tested the binary, although I guess they might be able to do some of that with codespaces.

However I still don't think adding GitHub specific configuration to this repo, especially for a product that's in beta, and thus likely to change, is a good idea.

MarcoFalke commented at 7:27 AM on February 3, 2021: member

No objection for now, but we should be extremely cautious about the cost/benefit tradeoff:

This is additional maintenance overhead. Every build-system change requires those files to be modified as well
Web-only contributions tend to be of lower quality (not to mention mobile-only, but luckily Codespaces doesn't work on mobile yet)
GitHub encouraging low quality spam contributions and at the same time ignore basic site stability and reliability has been haunting us for years and it is only getting worse: https://twitter.com/MarcoFalke/status/1355097159113322497
This will lock-in contributors to a narrow-minded GitHub-only workflow, thus excluding them from the workflow that we want early new contributors to participate in. The best way to start off contributing (with the goal of becoming a long-term contributor) is not by making a one-off contribution as quick as possible. The best way is to setup a dev environment that can be used for review to check out (compile, play with, test) other contributions.
This will lock-in ourselves a slightly bit more into the GitHub ecosystem. Our goal should be to move toward a mirror-only presence on GitHub and move the development toward a highly stable and reliable (maybe decentralized?) platform that works nicely with our review-requirements.

laanwj commented at 10:11 AM on February 3, 2021: member

100% agree with @MarcoFalke here.

This is additional maintenance overhead. Every build-system change requires those files to be modified as well

Though on the flip side it also helps users of vscode outside of github, and unlike the MSVC hierarchy it doesn't amount to a parallel build system. Just a broad "file mention".

in .vscode/settings.json:5 in 81d5df2710

   0 | @@ -0,0 +1,66 @@
   1 | +{
   2 | +    "extensions.ignoreRecommendations": true,
   3 | +    "extensions.showRecommendationsOnlyOnDemand": true,
   4 | +    "files.exclude": {
   5 | +        "**/*.a": true,

laanwj commented at 10:22 AM on February 3, 2021:

Isn't there a lot of overlap with .gitignore here? any reason these can't be unified? (or at least, programmatically generated from the same source)

practicalswift commented at 10:11 AM on February 4, 2021: contributor

Wouldn't it be useful to be able to point to an online IDE with a controlled environment so that say review club participants can experiment with changes in real time?

Kind of how online IPython notebooks are used: a controlled development environment accessible from the browser where one can tinker/experiment with the code in a risk-free fun easy way without making any commitments or time investments.

The goal of this PR is to make it easier to do such tinkering/experimenting. Tinkering/experimenting in this context does not include making actual public contributions/code changes. Public contributions typically come at a much much later stage (way beyond initial tinkering/experimenting) when one has invested in a local setup.

To be clear: I am not suggesting anyone should use this as a substitute for a proper local development setup. Also I'm not suggesting that this should be part of any "official" recommended workflow for contributors or similar: if you don't have any use for these four dotfiles you should be able to safely ignore them :)

michaelfolkson commented at 3:07 PM on February 4, 2021: contributor

making a small change and see the results of his/her work immediately while staying in the browser. Instant gratification! :)

This would be good for new contributors experimenting with changes to the GUI but as long as this repo shares the code of the GUI repo I'm opposed for all reasons stated above (GitHub dependence, spam etc).

I don't think we've had one PR review club on the GUI yet (not to say it won't happen in the future but hasn't been a focus)

As others have said the focus should be on growing the number of regular contributors/reviewers rather than providing early dopamine hits

Correction: We have had two PR review clubs on the GUI in over a year and a half.

ryanofsky commented at 3:48 PM on February 4, 2021: member

Code review ACK 81d5df271005934ebc033e9597b820731c8b5cd2. This seems great, but I haven't tried it ~and think a demo link would be helpful~.

Hand wringing over this seems strange to me. If the main concern is this will cause spam and low quality contributions, that's an empirical question, not something we need to speculate about. If it causes spam and low quality PRs, it should be pretty obvious and easy to fix by reverting.

But I really don't understand what what the concerns about lock-in and dependencies and ecosystems mean in a practical sense. This is no different than providing a .gitignore or a .clang-format file, or an init startup script. It may in fact be true that our bitcoind.service file has sent many developers down a dark road and some are attending anonymous groups to support withdrawal from systemd. But I think people should be able to use the tools they want to use, and as long as it doesn't cause an unacceptable maintenance burden, we should support it and try not to get in the way. This PR definitely adds some maintenance burden and it should be maintainers decision whether they want to take it on. But this can be stated plainly as a maintainer preference not a "really, we are protecting you from yourself" moral principle.

EDIT: Somehow I missed the "How to test this PR" section of the description. Will apply for access and try it out. It could definitely make sense to avoid merging the PR until the feature is more widely accessible.

laanwj added the label Brainstorming on Feb 5, 2021

laanwj added the label Scripts and tools on Feb 5, 2021

jonatack commented at 2:53 PM on February 6, 2021: member

I requested access 4 days ago (on writing my comment above) from GitHub to try it :watch:

MarcoFalke commented at 3:43 PM on February 6, 2021: member

Same here. I wanted to see how this interacts with our workflow. It might be too early to propose the changes here anyway when we can't test them.

practicalswift closed this on May 31, 2021

DrahtBot locked this on Aug 18, 2022