Page MenuHomestyx hydra
Files F206925

No OneTemporary
Actions

View Options

diff --git a/src/docs/contributor/bug_reports.diviner b/src/docs/contributor/bug_reports.diviner
index 7bdd5db31b..6a5fd115ce 100644
--- a/src/docs/contributor/bug_reports.diviner
+++ b/src/docs/contributor/bug_reports.diviner
@@ -1,205 +1,205 @@
@title Contributing Bug Reports
@group detail
Describes how to file an effective Phabricator bug report.
Overview
========
Found a bug with Phabricator? Let us know! This article describes how to file
an effective bug report so we can get your issue fixed or help you work around
it.
The most important things to do are:
- check the list of common fixes below;
- make sure Phabricator is up to date;
- make sure we support your setup;
- gather debugging information;
- explain how to reproduce the issue; and
- create a task in
[[ http://secure.phabricator.com/maniphest/task/create/ | Maniphest ]].
The rest of this article walks through these points in detail.
If you have a feature request (not a bug report), see
@{article:Contributing Feature Requests} for a more tailored guide.
For general information on contributing to Phabricator, see
@{article:Contributor Introduction}.
Common Fixes
============
Before you file a report, here are some common solutions to problems:
- **Update Phabricator**: We receive a lot of bug reports about issues we have
already fixed in HEAD. Updating often resolves issues. It is common for
issues to be fixed in less than 24 hours, so even if you've updated recently
you should update again. If you aren't sure how to update, see the next
section.
- **Update Libraries**: Make sure `libphutil/`, `arcanist/` and
`phabricator/` are all up to date. Users often update `phabricator/` but
forget to update `arcanist/` or `libphutil/`. When you update, make sure you
update all three libraries.
- **Restart Apache or PHP-FPM**: Phabricator uses caches which don't get
reset until you restart Apache or PHP-FPM. After updating, make sure you
restart.
Update Phabricator
==================
Before filing a bug, make sure you are up to date. We receive many bug reports
for issues we have already fixed, and even if we haven't fixed an issue we'll
be able to resolve it more easily if you file a report based on HEAD. (For
example, an old stack trace may not have the right line numbers, which will
make it more difficult for us to figure out what's going wrong.)
To update Phabricator, use a script like this one:
- http://www.phabricator.com/rsrc/install/update_phabricator.sh
+http://www.phabricator.com/rsrc/install/update_phabricator.sh
This script will require some adjustments depending on how your setup is
configured, which webserver you are using, etc.
**If you can not update** for some reason, please include the version of
Phabricator you are running in your report. The version is just the Git hash
of your local HEAD. You can find the version by running `git show` in
`phabricator/` and copy/pasting the first line of output, or by browsing to
{nav Config > All Settings} in the web UI and copy/pasting the information
at the top.
Supported Issues
================
Before filing a bug, make sure you're filing an issue against something we
support.
**We do NOT support prototype applications.** If you're running into an issue
with a prototype application, you're on your own. For more information about
prototype applications, see @{article:User Guide: Prototype Applications}.
**We do NOT support third-party packages or instructions.** If you installed
Phabricator (or configured some aspect of it) using a third-party package or by
following a third-party guide (like a blog post), we can not help you.
Phabricator changes quickly and third-party information is unreliable and often
falls out of date. Contact the maintainer of the package or guide you used,
or reinstall following the upstream instructions.
**We do NOT support custom code development or third-party libraries.** If
you're writing an extension, you're on your own. We provide some documentation,
but can not help you with extension or library development. If you downloaded a
library from somewhere, contact the library maintainer.
**We do NOT support bizarre environments.** If your issue is specific to an
unusual installation environment, we generally will not help you find a
workaround. Install Phabricator in a normal environment instead. Examples of
unusual environments are shared hosts, nontraditional hosts (gaming consoles,
storage appliances), and hosts with unusually tight resource constraints. The
vast majority of users run Phabricator in normal environments (modern computers
with root access) and these are the only environments we support.
Otherwise, if you're having an issue with a supported first-party application
and followed the upstream install instructions on a normal computer, we're happy
to try to help.
Getting More Information
========================
For some issues, there are places you can check for more information. This may
help you resolve the issue yourself. Even if it doesn't, this information can
help us figure out and resolve an issue.
- For issues with `arc` or any other command-line script, you can get more
details about what the script is doing by adding the `--trace` flag.
- For issues with Phabricator, check your webserver error logs.
- For Apache, this is often `/var/log/httpd/error.log`, or
`/var/log/apache2/error.log` or similar.
- For nginx, check both the nginx and php-fpm logs.
- For issues with the UI, check the Javascript error console in your web
browser.
- Some other things, like daemons, have their own debug flags or
troubleshooting steps. Check the documentation for information on
troubleshooting. Adjusting settings or enabling debugging modes may give
you more information about the issue.
Reproducibility
===============
The most important part of your report content is instructions on how to
reproduce the issue. What did you do? If you do it again, does it still break?
Does it depend on a specific browser? Can you reproduce the issue on
`secure.phabricator.com`?
Feel free to try to reproduce issues on the upstream install (which is kept near
HEAD), within reason -- it's okay to make a few test objects if you're having
trouble narrowing something down or want to check if updating might fix an
issue.
It is nearly impossible for us to resolve many issues if we can not reproduce
them.
Unreproducible Problems
=======================
Before we can fix a bug, we need to reproduce it. If we can't reproduce a
problem, we can't tell if we've fixed it and often won't be able to figure out
why it is occurring.
Most problems reproduce easily, but some are more difficult to reproduce. We
will generally make a reasonable effort to reproduce problems, but sometimes
we will be unable to reproduce an issue.
Many of these unreproducible issues turn out to be bizarre environmental
problems that are unique to one user's install, and figuring out what is wrong
takes a very long time with a lot of back and forth as we ask questions to
narrow down the cause of the problem. When we eventually figure it out and fix
it, few others benefit (in some cases, no one else). This sort of fishing
expedition is not a good use of anyone's time, and it's very hard for us to
prioritize solving these problems because they represent a huge effort for very
little benefit.
We will make a reasonable effort to reproduce problems, but can not help with
issues which we can't reproduce. You can make sure we're able to help resolve
your issue by generating clear reproduction steps.
Create a Task in Maniphest
==========================
If you're up to date, supported, have collected information about the problem,
and have the best reproduction instructions you can come up with, you're ready
to file an issue.
We'll look at any issue report we can find (we monitor IRC, email, GitHub,
StackOverflow, Quora, Facebook and Twitter), but the upstream Maniphest is
the authoritative bug tracker and the best place to file:
- https://secure.phabricator.com/maniphest/task/create/
+https://secure.phabricator.com/maniphest/task/create/
If you don't want to file there (or, for example, your bug relates to being
unable to log in or unable to file an issue in Maniphest) you can file on any
other channel, but we can address reports much more effectively if they're
filed against the upstream than if they're filed somewhere else.
| Effectiveness | Filing Method |
|---|---|
| Best | Upstream Maniphest |
| Okay | GitHub |
| Ehhh | Quora, StackOverflow, Facebook, email, etc. |
| What | Passive-aggressive tweet |
If you have a quick question or want to discuss something before filing an
issue, IRC is a great way to get a sanity check first. You can find information
about IRC in @{article: Give Feedback! Get Support!}.
Next Steps
==========
Continue by:
- learning about @{article: Contributing Feature Requests}; or
- reading general support information in
@{article: Give Feedback! Get Support!}; or
- returning to the @{article:Contributor Introduction}.
diff --git a/src/docs/contributor/feature_requests.diviner b/src/docs/contributor/feature_requests.diviner
index ec75deaf2a..d8c834958c 100644
--- a/src/docs/contributor/feature_requests.diviner
+++ b/src/docs/contributor/feature_requests.diviner
@@ -1,189 +1,189 @@
@title Contributing Feature Requests
@group detail
Describes how to file an effective Phabricator feature request.
Overview
========
Have a feature you'd like to see in Phabricator? This article describes how
to file an effective feature request.
The most important things to do are:
- understand the upstream;
- make sure your feature makes sense in the project;
- align your expectations around timelines and priorities;
- describe your problem, not your solution; and
- file a task in
[[ http://secure.phabricator.com/maniphest/task/create/ | Maniphest ]].
The rest of this article walks through these points in detail.
If you have a bug report (not a feature request), see
@{article:Contributing Bug Reports} for a more tailored guide.
For general information on contributing to Phabricator, see
@{article:Contributor Introduction}.
Understanding the Upstream
==========================
Before filing a feature request, it may be useful to understand how the
upstream operates.
The Phabricator upstream is [[ https://www.phacility.com | Phacility, Inc ]].
We maintain total control over the project and roadmap. There is no democratic
process, voting, or community-driven decision making. This model is better
at some things and worse at others than a more community-focused model would
be, but it is the model we operate under.
We have a cohesive vision for the project in the long term, and a general
roadmap that extends for years into the future. While the specifics of how
we get there are flexible, many major milestones are well-established.
Although we set project direction, the community is also a critical part of
Phabricator. We aren't all-knowing, and we rely on feedback to help us identify
issues, guide product direction, prioritize changes, and suggest features.
Feature requests are an important part of this, but we ultimately build only
features which make sense as part of the long term plan.
Since it's hard to absorb a detailed understanding of that vision, //describing
a problem// is often more effective than //requesting a feature//. We have the
context to develop solutions which fit into our plans, address similar use
cases, make sense with the available infrastructure, and work within the
boundaries of our product vision. For more details on this, see below.
Target Audiences
================
Some feature requests support very unusual use cases. Although we are broadly
inclusive of many different kinds of users and use cases, we are not trying
to make the software all things to all users. Use cases which are far afield
from the things the majority of users do with Phabricator often face substantial
barriers.
Phabricator is primarily targeted at software projects and organizations with
a heavy software focus. We are most likely to design, build, and prioritize
features which serve these organizations and projects.
Phabricator is primarily targeted at software professionals and other
professionals with adjacent responsibilities (like project management and
operations). Particularly, we assume users are proficient computer users and
familiar with software development concepts. We are most likely to design, build
and prioritize features which serve these users.
Phabricator is primarily targeted at professionals working in teams on full-time
projects. Particularly, we assume most users will use the software regularly and
are often willing to spend a little more time up front to get a more efficient
workflow in the long run. We are most likely to design, build and prioritize
features which serve these use cases.
Phabricator is not limited to these kinds of organizations, users and use cases,
but features which are aimed at a different group of users (like students,
casual projects, or inexperienced computer users) may be harder to get
upstreamed. Features aimed at very different groups of users (like wedding
planners, book clubs, or dogs) will be much harder to get upstreamed.
In many cases, a feature makes something better for all users. For example,
suppose we fixed an issue where colorblind users had difficulty doing something.
Dogs would benefit the most, but colorblind human users would also benefit, and
no one would be worse off. If the benefit for core users is very small these
kinds of features may be hard to prioritize, but there is no exceptional barrier
to getting them upstreamed.
In other cases, a feature makes something better for some users and worse for
other users. These kinds of features face a high barrier if they make the
software better at planning weddings and worse at reviewing code.
Setting Expectations
====================
We have a lot of users and a small team. Even if your feature is something we're
interested in and a good fit for where we want the product to go, it may take
us a long time to get around to building it.
We work full time on Phabricator, and our long-term roadmap has many years worth
of work. Your feature request is competing against thousands of other requests
for priority.
In general, we try to prioritize work that will have the greatest impact on the
most users. Many feature requests are perfectly reasonable requests, but have
very little impact, impact only a few users, and/or are complex to develop and
support relative to their impact. It can take us a long time to get to these.
Even if your feature request is simple and has substantial impact for a large
number of users, the size of the request queue means that it is mathematically
unlikely to be near the top.
You can find some information about how we prioritize in T4778. In particular,
we reprioritize frequently and can not accurately predict when we'll build a
feature which isn't very near to top of the queue.
As a whole, this means that the overwhelming majority of feature requests will
sit in queue for a long time without any updates, and that we won't be able to
give you any updates or predictions about timelines. One day, out of nowhere,
your feature will materialize. That day may be a decade from now. You should
have realistic expectations about this when filing a feature request.
If you want a concrete timeline, you can build the feature yourself. See
@{article:Contributing Code} for details and alternatives to working with the
upstream.
Describe Problems
=================
When you file a feature request, it is really helpful to describe the problem
you're facing first, not just your desired solution.
Often, your problem may have a lot in common with other similar problems. If we
understand your use case we can compare it to other use cases and sometimes find
a more powerful or more general solution which solves several problems at once.
At other times, we'll have a planned solution to the problem that might be
different from your desired solution but accomplish the same goal. Understanding
the root issue can let us merge and contextualize things.
Sometimes there's already a way to solve your problem that might just not be
obvious.
Finally, your proposed solution may not be compatible with the direction we
want to take the product, but we may be able to come up with another solution
which has approximately the same effect and does fit into the product direction.
If you only describe the solution and not the problem, we can't generalize,
contextualize, merge, reframe, or offer alternative solutions or workarounds.
Create a Task in Maniphest
==========================
If you think your feature might be a good fit for the upstream, have reasonable
expectations about it, and have a good description of the problem you're trying
to solve, you're ready to file a feature request:
- https://secure.phabricator.com/maniphest/task/create/
+https://secure.phabricator.com/maniphest/task/create/
You can file feature requests in places other than Maniphest (like GitHub), but
we can address them far more effectively if you file them in the upstream.
Feature requests filed elsewhere will generally be moved to the upstream.
If you have a quick question or want to discuss something before filing a
request, IRC is a great way to get a quick answer. You can find information
about IRC and other support channels in @{article: Give Feedback! Get Support!}.
Next Steps
==========
Continue by:
- learning about @{article: Contributing Bug Reports}; or
- reading general support information in
@{article: Give Feedback! Get Support!}; or
- returning to the @{article:Contributor Introduction}.
diff --git a/src/docs/contributor/using_oauthserver.diviner b/src/docs/contributor/using_oauthserver.diviner
index dad9b63b68..f460ed52bb 100644
--- a/src/docs/contributor/using_oauthserver.diviner
+++ b/src/docs/contributor/using_oauthserver.diviner
@@ -1,120 +1,120 @@
@title Using the Phabricator OAuth Server
@group developer
How to use the Phabricator OAuth Server.
= Overview =
Phabricator includes an OAuth Server which supports the
`Authorization Code Grant` flow as described in the OAuth 2.0
specification:
http://tools.ietf.org/html/draft-ietf-oauth-v2-23
This functionality can allow clients to integrate with a given
Phabricator instance in a secure way with granular data access.
For example, Phabricator can be used as a central identity store for any
clients that implement OAuth 2.0.
= Vocabulary =
- **Access token** - a token which allows a client to ask for data on
behalf of a resource owner. A given client will only be able to access
data included in the scope(s) the resource owner authorized that client for.
- **Authorization code** - a short-lived code which allows an authenticated
client to ask for an access token on behalf of some resource owner.
- **Client** - this is the application or system asking for data from the
OAuth Server on behalf of the resource owner.
- **Resource owner** - this is the user the client and OAuth Server are
concerned with on a given request.
- **Scope** - this defines a specific piece of granular data a client can
or can not access on behalf of a user. For example, if authorized for the
"whoami" scope on behalf of a given resource owner, the client can get the
results of Conduit.whoami for that resource owner when authenticated with
a valid access token.
= Setup - Creating a Client =
# Visit https://phabricator.example.com/oauthserver/client/create/
# Fill out the form
# Profit
= Obtaining an Authorization Code =
POST or GET https://phabricator.example.com/oauthserver/auth/ with the
following parameters:
- Required - **client_id** - the id of the newly registered client.
- Required - **response_type** - the desired type of authorization code
response. Only code is supported at this time.
- Optional - **redirect_uri** - override the redirect_uri the client
registered. This redirect_uri must have the same fully-qualified domain
and have at least the same query parameters as the redirect_uri the client
registered, as well as have no fragments.
- Optional - **scope** - specify what scope(s) the client needs access to
in a space-delimited list.
- Optional - **state** - an opaque value the client can send to the server
for programmatic excellence. Some clients use this value to implement XSRF
protection or for debugging purposes.
If done correctly and the resource owner has not yet authorized the client
for the desired scope, then the resource owner will be presented with an
interface to authorize the client for the desired scope. The OAuth Server
will redirect to the pertinent redirect_uri with an authorization code or
an error indicating the resource owner did not authorize the client, depending.
If done correctly and the resource owner has already authorized the client for
the desired scope, then the OAuth Server will redirect to the pertinent
redirect_uri with a valid authorization code.
If there is an error, the OAuth Server will return a descriptive error
message. This error will be presented to the resource owner on the
Phabricator domain if there is reason to believe there is something fishy
with the client. For example, if there is an issue with the redirect_uri.
Otherwise, the OAuth Server will redirect to the pertinent redirect_uri
and include the pertinent error information.
= Obtaining an Access Token =
POST or GET https://phabricator.example.com/oauthserver/token/
with the following parameters:
- Required - **client_id** - the id of the client
- Required - **client_secret** - the secret of the client.
This is used to authenticate the client.
- Required - **code** - the authorization code obtained earlier.
- Required - **grant_type** - the desired type of access grant.
Only token is supported at this time.
- Optional - **redirect_uri** - should be the exact same redirect_uri as
the redirect_uri specified to obtain the authorization code. If no
redirect_uri was specified to obtain the authorization code then this
should not be specified.
If done correctly, the OAuth Server will redirect to the pertinent
redirect_uri with an access token.
If there is an error, the OAuth Server will return a descriptive error
message.
= Using an Access Token =
Simply include a query param with the key of "access_token" and the value
as the earlier obtained access token. For example:
- https://phabricator.example.com/api/user.whoami?access_token=ykc7ly7vtibj334oga4fnfbuvnwz4ocp
+https://phabricator.example.com/api/user.whoami?access_token=ykc7ly7vtibj334oga4fnfbuvnwz4ocp
If the token has expired or is otherwise invalid, the client will receive
an error indicating as such. In these cases, the client should re-initiate
the entire ##Authorization Code Grant## flow.
NOTE: See "Scopes" section below for more information on what data is
currently exposed through the OAuth Server.
= Scopes =
There are only two scopes supported at this time.
- **offline_access** - allows an access token to work indefinitely without
expiring.
- **whoami** - allows the client to access the results of Conduit.whoami on
behalf of the resource owner.
diff --git a/src/docs/user/installation_guide.diviner b/src/docs/user/installation_guide.diviner
index d1739156e4..615ad63fda 100644
--- a/src/docs/user/installation_guide.diviner
+++ b/src/docs/user/installation_guide.diviner
@@ -1,189 +1,189 @@
@title Installation Guide
@group intro
This document contains basic install instructions to get Phabricator up and
running.
Overview
========
Phabricator is a LAMP (Linux, Apache, MySQL, PHP) application. To install
Phabricator, you will need:
- a normal computer to install it on (shared hosts and unusual environments
are not supported) running some flavor of Linux or a similar OS;
- a domain name (like `phabricator.mycompany.com`);
- basic sysadmin skills;
- Apache, nginx, or another webserver;
- PHP, MySQL, and Git.
The remainder of this document details these requirements.
Installation Requirements
=========================
You will need **a computer**. Options include:
- **A Normal Computer**: This is strongly recommended. Many installs use a VM
in EC2. Phabricator installs properly and works well on a normal computer.
- **A Shared Host**: This may work, but is not recommended. Many shared
hosting environments have restrictions which prevent some of Phabricator's
features from working. Consider using a normal computer instead. We do not
support shared hosts.
- **A SAN Appliance, Network Router, Gaming Console, Raspberry Pi, etc.**:
Although you may be able to install Phabricator on specialized hardware, it
is unlikely to work well and will be difficult for us to support. Strongly
consider using a normal computer instead. We do not support specialized
hardware.
- **A Toaster, Car, Firearm, Thermostat, etc.**: Yes, many modern devices now
have embedded computing capability. We live in interesting times. However,
you should not install Phabricator on these devices. Instead, install it on
a normal computer. We do not support installing on noncomputing devices.
To install the Phabricator server software, you will need an **operating
system** on your normal computer which is **not Windows**. Note that the
command line interface //does// work on Windows, and you can //use//
Phabricator from any operating system with a web browser. However, the server
software does not run on Windows. It does run on most other operating systems,
so choose one of these instead:
- **Linux**: Most installs use Linux.
- **Mac OS X**: Mac OS X is an acceptable flavor of Linux.
- **FreeBSD**: While FreeBSD is certainly not a flavor of Linux, it is a fine
operating system possessed of many desirable qualities, and Phabricator will
install and run properly on FreeBSD.
- **Solaris, etc.**: Other systems which look like Linux and quack like Linux
will generally work fine, although we may suffer a reduced ability to
support and resolve issues on unusual operating systems.
Beyond an operating system, you will need **a webserver**.
- **Apache**: Many installs use Apache + `mod_php`.
- **nginx**: Many installs use nginx + `php-fpm`.
- **lighttpd**: `lighttpd` is less popular than Apache or nginx, but it
works fine.
- **Other**: Other webservers which can run PHP are also likely to work fine,
although these installation instructions will not cover how to set them up.
- **PHP Builtin Server**: You can use the builtin PHP webserver for
development or testing, although it should not be used in production.
You will also need:
- **MySQL**: You need MySQL. We strongly recommend MySQL 5.5 or newer.
- **PHP**: You need PHP 5.2 or newer.
You'll probably also need a **domain name**. In particular, you should read this
note:
NOTE: Phabricator must be installed on an entire domain. You can not install it
to a path on an existing domain, like `example.com/phabricator/`. Instead,
install it to an entire domain or subdomain, like `phabricator.example.com`.
Level Requirements
==================
To install and administrate Phabricator, you'll need to be comfortable with
common system administration skills. For example, you should be familiar with
using the command line, installing software on your operating system of choice,
working with the filesystem, managing processes, dealing with permissions,
editing configuration files, and setting environment variables.
If you aren't comfortable with these skills, you can still try to perform an
install. The install documentation will attempt to guide you through what you
need to know. However, if you aren't very familiar or comfortable with using
this set of skills to troubleshoot and resolve problems, you may encounter
issues which you have substantial difficulty working through.
We assume users installing and administrating Phabricator are comfortable with
common system administration skills and concepts. If you aren't, proceed at
your own risk and expect that your skills may be tested.
Installing Required Components
==============================
If you are installing on Ubuntu or an RedHat derivative, there are install
scripts available which should handle most of the things discussed in this
document for you:
- **RedHat Derivatives**:
<http://www.phabricator.com/rsrc/install/install_rhel-derivs.sh>
- **Ubuntu**: <http://www.phabricator.com/rsrc/install/install_ubuntu.sh>
If those work for you, you can skip directly to the
@{article:Configuration Guide}. These scripts are also available in the
`scripts/install` directory in the project itself.
Otherwise, here's a general description of what you need to install:
- git (usually called "git" in package management systems)
- Apache (usually "httpd" or "apache2") (or nginx)
- MySQL Server (usually "mysqld" or "mysql-server")
- PHP (usually "php")
- Required PHP extensions: mbstring, iconv, mysql (or mysqli), curl, pcntl
(these might be something like "php-mysql" or "php5-mysql")
- Optional PHP extensions: gd, apc (special instructions for APC are available
below if you have difficulty installing it), xhprof (instructions below,
you only need this if you are developing Phabricator)
If you already have LAMP setup, you've probably already got everything you need.
It may also be helpful to refer to the install scripts above, even if they don't
work for your system.
Now that you have all that stuff installed, grab Phabricator and its
dependencies:
$ cd somewhere/ # pick some install directory
somewhere/ $ git clone https://github.com/phacility/libphutil.git
somewhere/ $ git clone https://github.com/phacility/arcanist.git
somewhere/ $ git clone https://github.com/phacility/phabricator.git
= Installing APC (Optional) =
Like everything else written in PHP, Phabricator will run much faster with APC
installed. You likely need to install "pcre-devel" first:
sudo yum install pcre-devel
Then you have two options. Either install via PECL (try this first):
sudo yum install php-pear
sudo pecl install apc
**If that doesn't work**, grab the package from PECL directly and follow the
build instructions there:
- http://pecl.php.net/package/APC
+http://pecl.php.net/package/APC
Installing APC is optional but **strongly recommended**, especially on
production hosts.
Once APC is installed, test that it is available by running:
php -i | grep apc
If it doesn't show up, add:
extension=apc.so
..to "/etc/php.d/apc.ini" or the "php.ini" file indicated by "php -i".
= Updating Phabricator =
Since Phabricator is under active development, you should update frequently. To
update Phabricator:
- Stop the webserver (including `php-fpm`, if you use it).
- Run `git pull` in `libphutil/`, `arcanist/` and `phabricator/`.
- Run `phabricator/bin/storage upgrade`.
- Restart the webserver (and `php-fpm`, if you stopped it earlier).
For more details, see @{article:Configuration Guide}. You can use a script
similar to this one to automate the process:
- http://www.phabricator.com/rsrc/install/update_phabricator.sh
+http://www.phabricator.com/rsrc/install/update_phabricator.sh
= Next Steps =
Continue by:
- configuring Phabricator with the @{article:Configuration Guide}.
diff --git a/src/docs/user/userguide/arcanist_coverage.diviner b/src/docs/user/userguide/arcanist_coverage.diviner
index 9b37840746..18339c7b05 100644
--- a/src/docs/user/userguide/arcanist_coverage.diviner
+++ b/src/docs/user/userguide/arcanist_coverage.diviner
@@ -1,69 +1,69 @@
@title Arcanist User Guide: Code Coverage
@group userguide
Explains code coverage features in Arcanist and Phabricator.
This is a configuration guide that helps you set up advanced features. If you're
just getting started, you don't need to look at this yet. Instead, start with
the @{article:Arcanist User Guide}.
Before you can configure coverage features, you must set up unit test
integration. For instructions, see @{article:Arcanist User Guide: Configuring
a New Project} and @{article:Arcanist User Guide: Customizing
Lint, Unit Tests and Workflows}.
= Using Coverage Features =
If your project has unit tests with coverage integration (see below for
instructions on setting it up), you can use "arc" to show coverage reports.
For example:
arc unit --detailed-coverage src/some/file.php
Depending on how your test engine is configured, this will run tests relevant
to ##src/some/file.php## and give you a detailed coverage report.
If the test engine enables coverage by default, it will be uploaded to
Differential and displayed in the right gutter when viewing diffs.
= Enabling Coverage for libphutil, Arcanist and Phabricator =
If you're contributing, libphutil, Arcanist and Phabricator support coverage if
you install Xdebug:
- http://xdebug.org/
+http://xdebug.org/
It should be sufficient to correctly install Xdebug; coverage information will
be automatically enabled.
= Building Coverage Support =
To add coverage support to a unit test engine, just call ##setCoverage()## when
building @{class@arcanist:ArcanistUnitTestResult} objects. Provide a map of
file names (relative to the working copy root) to coverage report strings.
Coverage report strings look like this:
NNNNNCCCNNNNNNNNCCCCCCNNNUUUNNNNN
Each line in the file is represented by a character. Valid characters are:
- **N** Not executable. This is a comment or whitespace which should be
ignored when computing test coverage.
- **C** Covered. This line has test coverage.
- **U** Uncovered. This line is executable but has no test coverage.
- **X** Unreachable. If your coverage analysis can detect unreachable code,
you can report it here.
This format is intended to be as simple as possible. A valid coverage result
might look like this:
array(
'src/example.php' => 'NNCNNNCNUNNNUNUNUNUNUNC',
'src/other.php' => 'NNUNNNUNCNNNUNUNCNCNCNU',
);
You may also want to filter coverage information to the paths passed to the
unit test engine. See @{class@arcanist:ArcanistPhutilTestCase} and
@{class@arcanist:PhutilUnitTestEngine} for an example of coverage integration
in PHP using Xdebug.
diff --git a/src/docs/user/userguide/diffusion.diviner b/src/docs/user/userguide/diffusion.diviner
index ab3b789425..1f4f08295f 100644
--- a/src/docs/user/userguide/diffusion.diviner
+++ b/src/docs/user/userguide/diffusion.diviner
@@ -1,102 +1,102 @@
@title Diffusion User Guide
@group userguide
Guide to Diffusion, the Phabricator repository browser.
= Overview =
Diffusion is a repository browser which allows you to explore source code in a
Subversion, Git, or Mercurial repository. It is somewhat similar to software
like Trac and GitWeb.
Diffusion can either import a read-only copy of repositories hosted somewhere
else (for example, from GitHub, Bitbucket or existing hosting) or host
repositories within Phabricator. Hosted repositories support a variety of
triggers and access controls.
Diffusion is integrated with the other tools in the Phabricator suite. For
instance:
- when you commit Differential revisions to a tracked repository, they are
automatically updated and linked to the corresponding commits;
- you can add Herald rules to notify you about commits that match certain
rules;
- for hosted repositories, Herald can enforce granular access control rules;
- in all the tools, commit names are automatically linked.
= Adding Repositories =
Repository administration is accomplished through Diffusion. You can use the
web interface in Diffusion to import an external repository, or create a new
hosted repository.
- For hosted repositories, make sure you go through the setup instructions
in @{article:Diffusion User Guide: Repository Hosting} first.
- For all repositories, you'll need to be running the daemons. If you have
not set them up yet, see @{article:Managing Daemons with phd}.
By default, you must be an administrator to create a new repository.
= Repository Callsigns and Commit Names =
Each repository is identified by a "callsign", which is a short uppercase string
like "P" (for Phabricator) or "ARC" (for Arcanist).
Each repository must have a unique callsign. Callsigns must be unique within
an install but do not need to be globally unique, so you are free to use the
single-letter callsigns for brevity. For example, Facebook uses "E" for the
Engineering repository, "O" for the Ops repository, "Y" for a Yum package
repository, and so on, while Phabricator uses "P", "ARC", "PHU" for libphutil,
and "J" for Javelin. Keeping callsigns brief will make them easier to use, and
the use of one-character callsigns is recommended if they are reasonably
evocative and you have no more than 26 tracked repositories.
The primary goal of callsigns is to namespace commits to SVN repositories: if
you use multiple SVN repositories, each repository has a revision 1, revision 2,
etc., so referring to them by number alone is ambiguous. However, even for Git
they impart additional information to human readers and allow parsers to detect
that something is a commit name with high probability (and allow distinguishing
between multiple copies of a repository).
Diffusion uses this callsign and information about the commit itself to generate
a commit name, like "rE12345" or "rP28146171ce1278f2375e3646a1e1ea3fd56fc5a3".
The "r" stands for "revision". It is followed by the repository callsign, and
then a VCS-specific commit identifier (for SVN, the commit number; for Git and
Mercurial, the commit hash). When writing the name of a Git commit you may
abbreviate the hash, but note that hash collisions are probable for short prefix
lengths. See this post on the LKML for a historical explanation of Git's
occasional internal use of 7-character hashes:
- https://lkml.org/lkml/2010/10/28/287
+https://lkml.org/lkml/2010/10/28/287
Because 7-character hashes are likely to collide for even moderately large
repositories, Diffusion generally uses either a 16-character prefix (which makes
collisions very unlikely) or the full 40-character hash (which makes collisions
astronomically unlikely).
= Running Diffusion Daemons =
In most cases, it is sufficient to run:
phabricator/bin/ $ ./phd start
...to start the daemons. For a more in-depth explanation of `phd` and daemons,
see @{article:Managing Daemons with phd}.
NOTE: If you have an unusually large install with multiple web frontends, see
notes in @{article:Managing Daemons with phd}.
You can use the repository detail screen and the Daemon Console to monitor the
daemons and their progress importing the repository. Small repositories should
import quickly, while larger repositories may take some time. Commits should
begin appearing in Diffusion within a few minutes for all but the largest
repositories.
= Next Steps =
- Learn about creating a symbol index at
@{article:Diffusion User Guide: Symbol Indexes}; or
- set up repository hosting with
@{article:Diffusion User Guide: Repository Hosting}; or
- understand daemons in detail with @{article:Managing Daemons with phd}; or
- give us feedback at @{article:Give Feedback! Get Support!}.
diff --git a/src/docs/user/userguide/external_editor.diviner b/src/docs/user/userguide/external_editor.diviner
index c98ccb1903..b818a335d0 100644
--- a/src/docs/user/userguide/external_editor.diviner
+++ b/src/docs/user/userguide/external_editor.diviner
@@ -1,51 +1,51 @@
@title User Guide: Configuring an External Editor
@group userguide
Setting up an external editor to integrate with Diffusion and Differential.
= Overview =
You can configure a URI handler to allow you to open files from Differential
and Diffusion in your preferred text editor.
= Configuring Editors =
To configure an external editor, go to {nav Settings > Application Settings >
Display Preferences} and set "Editor Link" to a URI pattern (see below). This
will enable an "Open in Editor" link in Differential, and an "Edit" button in
Diffusion.
In general, you'll set this field to something like:
lang=uri
editor://open/?file=%f
Some editors support opening multiple files at once when filenames are separated
by spaces. If your editor supports this feature, set "Edit Multiple Files" to
"Supported". Otherwise, you can set it to "Not Supported" to disable "Open All"
buttons in the interface.
== Configuring: TextMate on OS X ==
TextMate installs a ##txmt://## handler by default, so it's easy to configure
this feature if you use TextMate.
First, create a local directory with symlinks for each repository callsign. For
example, if you're developing Phabricator, it might look like this:
/Users/alincoln/editor_links/ $ ls -l
... ARC -> /Users/alincoln/workspace/arcanist/
... P -> /Users/alincoln/workspace/phabricator/
... PHU -> /Users/alincoln/workspace/libphutil/
Then set your "Editor Link" to:
lang=uri
txmt://open/?url=file:///Users/alincoln/editor_links/%r/%f&line=%l
== Configuring: Other Editors ==
General instructions for configuring some other editors and environments can be
found here:
- http://wiki.nette.org/en/howto-editor-link
+http://wiki.nette.org/en/howto-editor-link

File Metadata

Mime Type
text/x-diff
Expires
Tue, Jul 1, 6:43 PM (17 h, 22 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
164521
Default Alt Text
(41 KB)

Event Timeline

styx copyright 2020 sirocyl / ellie (kymkdd) / ncommander / styx contributors
Use of other names and brands is not intended to reflect a claim of, or right to, use the name or brand.
styx is an operating system using the Linux kernel and components, and "styx Linux" as a phrase does not reflect the inclusion of the Linux brand or trademark in the styx project.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
Terms and Conditions (TODO: fix this!)