Development FAQ

Open Y Developer FAQ

Local Development

Getting started with a local environment

To start developing you need to obtain the latest Open Y codebase. See the openy-project repository for the full process.

This video tutorial will walk you through how to initiate a local development environment.

The Open Y team has pre-built environments and walkthroughs using either Vagrant and VirtualBox or Docker and Docksal. Choose the method that you’re most comfortable with and get started!

Gathering information about your local environment

To best troubleshoot issues, it’s helpful for the Open Y team to have as much information about your environment as possible. Before you ask for help, watch this tutorial on how to gather that information.

Debugging with Xdebug in your local

The Docksal project maintains detailed information for using Xdebug with VSCode, PHPStorm, and more.


Who should I specify for review?

We have a best practice to get at least 2 independent reviews before merging code. Please request a review from the Open Y Lead Technical Architect (Andrii Podanenko, @podarok) and somebody else (from your team or another Open Y partner).

Who is responsible for merging?

The Open Y Lead Technical Architect (Andrii Podanenko, @podarok) is responsible for final approval, merging, and release management on the Open Y project.

What labels in PRs should I use?

What milestone should I specify?

Why I can’t add labels or specify milestones?

All of these require you to be granted Contributor access to the Open Y GitHub repository. Contact the Open Y Lead Technical Architect (Andrii Podanenko, @podarok) to get access. Labels are usually set by the Open Y Core Team.

Why are the steps for review in Pull Requests so important?

When you send your code for review our team must know both how to review the code and what to test to verify the functionality. You are the only source of truth for how to check functionality. Adding steps for review will help the reviewer and QA team to verify that the issue is resolved.

Why should I add a reference to the GitHub issue in my PR description?

As we are a community-led project, there may be a long time between creating an issue and resolving it in a Pull Request. The reviewer should be able to understand the context and possible discussion around the issue to be resolved with your PR. The more context we have, the better and faster we can review the request.

In what format should I add commits, should I add internal Jira task ID or GitHub issue?

It is important to make commit messages with some sort of sense for the human to read them when digging back in history. Adding any task identifications from the project management system is allowed.

What is the “DeepCode” bot?

DeepCode bot is the automated, machine learning code review system that analyses huge amounts of GitHub repositories and is sometimes useful to find common issues before humans do reviews. It is helpful, but not always necessary to fix issues found by the DeepCode bot because sometimes it fails. If you see a comment be sure to read the report. If the report makes sense, then fix the issue suggested by the bot.

Build Automation & CI

What CI processes does Open Y have in place?

To get a fully working Open Y site for the code change you are about to push for review there is a build generating system installed for the Open Y GitHub repository that automatically generates a dedicated temporary website with your changes applied.

Why are some builds created automatically and some not?

By default, builds are configured for trusted users, so if you are getting a message from the bot like

“Can one of the admins verify this patch? Use “o+k to test” or ‘’t+est this please” for manual build execution."

then your username is not in the allowlist and somebody from the Open Y Core Team can comment to initiate a build for you. Contact @podarok to get your build generated or your name added to the allowlist.

How do I create a build for my PR?

If you are on the allowlist then simply create a Pull Request from your fork to the Open Y repository. After up to 30 minutes you’ll receive comments with links to the generated site builds.

When are builds deleted from the server?

Usually, you have a day for the build to be wiped out from the server. If there is an upcoming deadline and many PRs are coming in, the lifetime could be significantly shorter, down to a couple of hours.

Who should I contact to get logs from the build server?

Andrii Podanenko @podarok or Dima Danylevskyi @danylevskyi

What should I do if tests fail?

If you have any concerns with reports generated by the code checkers that are used in Open Y ask Open Y Lead Technical Architect Andrii Podanenko to get them resolved. The majority of these systems are works-in-progress and it is helpful to have feedback on them.

How do I install Open Y on Pantheon hosting

See request from a community. The solution is described in Pantheon’s documentation on nested docroots. We suggest that you maintain your own composer.json with the specified web-root directory, as described in the Pantheon examples.