Page MenuHomePhorge

Build a Phorge Developer Environment
Open, Needs TriagePublic

Description

Container task for everything related to building out tooling to help contributors build and test code for Phorge

I feel that this is a few topics

  • Contribution guidelines
    • How can I submit revisions?
    • How do I get permissions? etc.
    • What are the rules and guidelines?
  • Platform Documentation (Diviner builds some of this)
    • And also how to run tests and build tests
  • Docker Container

Event Timeline

We should consider a Vagrantfile in place of docker containers. I think it will be more approachable to newcomers having a single VM with all the services/configurations setup compared to managing multiple containers.

Separately, developing on Windows has its own complications

  • I ran into some issues with windows-style vs. unix-style line endings. I think this can be resolved with a configuration but the warning messages spit out by git are confusing
  • I think git on windows uses its own built-in ssh which doesn't seem to play well with the ssh-agent running on the system. Despite adding my key to the ssh-agent and confirming it's in there the git commands refuse to acknowledge it -- I think arcanist bombs if a git command results in prompting for user input which has made this difficult. I haven't yet figured out how to get this working, possibly some use of GIT_SSH_COMMAND though my initial attempts did not succeed
  • xhpast is configured to run for lint/ut but there is no xhpast binary for windows systems. It looks like someone has written up a way to do this but it involves installing a compiler and compiling it x_x

I have a plan for a single docker container for developing extensions.
It's really a question of "what will people like", so maybe throw everything at the wall and see what sticks.

In T15011#363, @speck wrote:

We should consider a Vagrantfile in place of docker containers. I think it will be more approachable to newcomers having a single VM with all the services/configurations setup compared to managing multiple containers.

Separately, developing on Windows has its own complications

We should consider a Vagrantfile in place of docker containers.

I haven't used Vagrant, however I think I am cool with any setup as long as it is:

  • Run a couple commands, and done
  • Works in WSL and VSCode

I would throw in though that docker-compose accomplishes nearly the same thing by coordinating the containers so it can be run by simply executing docker-compose up

Separately, developing on Windows has its own complications

  • Solution to (almost) all Windows developer problems = WSL !!!!! (specifically WSL2 which is amazing)
    • Changed my life
    • Supports containers
    • Supports VSCode out of box
    • No more windows problems
In T15011#366, @avivey wrote:

I have a plan for a single docker container for developing extensions.

Good point and awesome! - We could have multiple environments depending on what you are developing

I actually started on a VSCode Devcontainer based solution on my GitHub: https://github.com/willson556/phorge-devcontainer

It is working pretty well with notifications and repository hosting both configured out of the box. My only concern with the config at the moment is that it's very much setup for development -- we would want to clearly document that it is not to be used as a starting point for a production docker-compose setup!

Any feedback would be appreciated!

I actually started on a VSCode Devcontainer based solution on my GitHub: https://github.com/willson556/phorge-devcontainer

It is working pretty well with notifications and repository hosting both configured out of the box. My only concern with the config at the moment is that it's very much setup for development -- we would want to clearly document that it is not to be used as a starting point for a production docker-compose setup!

Any feedback would be appreciated!

@willson556 This looks pretty awesome - I am going to try it in a bit, my very first thought though is allow the http port to be configurable through an ENV var... I locally run can internal app on port 80 almost all the time, so it would be nice to be able to set an ENV Var for this to run on some other configurable port

A few things @willson556

  • Untracked file in phorge source support/aphlict/server/package-lock.json
root@63c842bff39e:/srv/phorge/phorge# git status
On branch master
Your branch is up to date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        support/aphlict/server/package-lock.json

nothing added to commit but untracked files present (use "git add" to track)

rP .arcconfig is pointing at secure.phabricator.com - Which will be fixed by D25001 I assume
Same issue in rARC .arcconfig is pointing at secure.phabricator.com - - But no revision exists yet - Made D25003

Ports
Like I mentioned T15011#372 ports should be env

Looks like this is pretty awesome overall! -

A few things @willson556

  • Untracked file in phorge source support/aphlict/server/package-lock.json

This is probably a result of the process for getting Aphlict up and running. The documentation for installing Aphlict instructs you to npm install ws in the support/aphlict/server/ folder but it looks since that documentation was written newer versions of node/npm will write out package-lock.json which the repository is not setup to ignore. We'll need to add that file to the .gitignore file I think.

In T15011#390, @speck wrote:

The documentation for installing Aphlict instructs you to npm install ws in the support/aphlict/server/ folder but it looks since that documentation was written newer versions of node/npm will write out package-lock.json which the repository is not setup to ignore. We'll need to add that file to the .gitignore file I think.

Another option might be to update instructions to npm install ws --no-package-lock which I believe will stop npm from generating the lock file

Although like you said .gitignore is probs the best option

Ah I wasn't aware of that option. I created D25004: Update .gitignore to account for package-lock.json if we want to update the .gitignore

@willson556: phorge-devcontainer looks awesome. I'll try it out asap. I may be able to contribute as well, I've got a bit of experience building reusable development environments.

We should consider a Vagrantfile

Also a fan of the Vagrant pattern. I'm willing to help out here.

I want to also mention on this topic... Using a pre-packaged VirtualBox image can be a straightforward distribution route, with a drawback being filesize... Perhaps Torrents could be a neat way alternative to distribute something like that, though there would be a few options including sponsored mirrors, etc... VirtualBox is a common Vagrant provider, so oftentimes it is a prerequisite anyway...

From my perspective, considering all of Linux, Windows, and MacOS equally, the most straightforward ways to get up and running cross-platform would be in order, for someone who just wants to smoothly get started contributing code and doesn't already have any of these things setup, regardless of development OS:

  1. Virtualbox image
  2. Vagrant
  3. Docker

The tradeoffs for the VB image may be great enough to where Vagrant is preferred... Plus the auto networking configuration of Vagrant might make it more appealing and reduce documentation and support...

Definitely liking the idea of a Vagrant setup, but wanted to mention that going straight to VirtualBox is also an option, and could likely be available already to someone who has Vagrant installed

I actually started on a VSCode Devcontainer based solution on my GitHub: https://github.com/willson556/phorge-devcontainer

So this phorge-devcontainer seems totally awesome... it looks very clean and thorough on first glance... May be able to adapt some of the provisioning script concepts for a Vagrant setup as well :)

I use PHPStorm as a primary IDE, and phorge-devcontainer seems targeted towards VSCode. VSCode is a great lighter-weight IDE and I keep it installed for quick opens... I would personally prefer to use PHPStorm since it's an option for me, and objectively an efficient platform as well. But not really opposed to a community-recommended guideline that would encourage me to use a different IDE for this project since VSCode is generally very acceptable.. But IDE flexibility seems ideal....

I might be tempted to come up with a VirtualBox with a complete dev environment and OS including phorge-devcontainer provisioning and VSCode preinstalled, where all development can take place inside the VM.. but I'm not sure how well-received or supportable that would be...

But I'd be interested in tackling the challenge of coming up with a generic provisioning pattern that would happen on vagrant up, ideally compatible with the Docker setup, and I already have an extensive toolbox to help make this happen...

@speck Any thoughts on some of this? As someone else who appreciates some of the benefits of using a complete accessible VM (e.g. via Vagrant)?

I've used both docker containers and vagrantfiles for development, though not too extensively. In my experience they're both pretty involved for something that requires multiple services running. I think vagrantfile might be a little more accessible for developers. Using docker will eventually require additional understanding of docker/docker-compose and how containers interact whereas virtual machines I think are easier to reason about. For example I think it will be very common for a developer to want to get to a command-line on the system running their phorge services. Doing so with docker requires knowing which container you want (docker container ls) and running an interactive bash (docker exec --it {id} bash). With vagrant it automatically sets up ssh (and handling keys, somehow) so you can do something like vagrant ssh and it drops you into bash on a single machine that has all services running.

I think both solutions work well and I don't feel too strongly one way or the other. Most of my bias towards vagrant is for onboarding developers with little to no experience with docker.

I think both solutions work well

I think since alot will depend on developer preference, we can just provide multiple options. The biggest issue ends up supporting the code behind the environments into the future.

So - we could have a vs-code .dockerfile environemnt, that will work for anyone using vscode (whether windows or mac, or windows with wsl)
We could also prove the Vagrantfile environment for those that want to use that.

We should just decide what our requirements are to bring these repos into Phorge and then support them (we may decide that these things all live on github and "use at own risk" - But, I feel strongly that we should provide 1 or more paths to developers that want to jump in and get to writing code...