Summary of changes from April 17, 2019 to April 27, 2019.
| Codebase | Repository | {icon lock} | HEAD | Activity |
|----------|------------|--|------|----------|
| Phabricator | rP | | rPc0a4d1de13 | 43 commits |
| Arcanist | rARC | | rARC9830c931 | 0 commits |
| libphutil | rPHU | | rPHU639e4b9 | 0 commits |
| Instances (SAAS) | rSAAS | {icon lock} | rSAAS5e60851 | 0 commits |
| Services (SAAS) | rSERVICES | {icon lock} | rSERVICES5424383 | 1 commit |
| Core (SAAS) | rCORE | {icon lock} | rCORE78c222b | 0 commits |
(WARNING) These changes have not yet promoted to `stable`.
These changes have a substantial impact on some repository behavior and didn't line up well with the release cycle, so it seems likely they will benefit from more thorough testing. They are expected to promote next week.
General
=======
[{icon tint, color=sky}] Most changes in this release focus on the repository import process. The pipeline has substantial technical changes, but the major user-facing change is in how we handle commits which users push to repositories with the hope that Phabricator will mostly ignore them (e.g., not send email, not close related tasks and revisions, and so on).
Historically, Phabricator assumed that `git push` generally meant "publish changes" (that is: "these are final, permanent changes which are ready to deploy"), and you needed to go out of your way to configure different behavior. Long ago, this assumption was a good assumption for `svn commit`, but is not true often enough to feel like a good default for `git push`. In particular:
- application software (including Phabricator, sort of) often uses `refs/...` as a holding area for temporary or draft changes that are not really published or permanent; and
- in some workflows, users use `git push` to mean "save changes", frequently pushing to temporary branches with names like `tmp-bugfix-123-do-not-delete`.
Phabricator now uses these rules:
- Refs are now separated into "Permanent Refs" and other refs.
- By default, all branches are permanent refs. All other refs are not "Permanent Refs". For example, tags are not "Permanent Refs", and `refs/pull/123` is not a "Permanent Ref".
- A commit is only considered "published" once it becomes an ancestor of (that is, reachable from) a "Permanent Ref".
- Until a commit is an ancestor of a permanent ref, it is "unpublished".
- If you only want some branches to have this behavior ("master", "stable"; not "tmp-bugfix-123"), you can configure which branches are "Permanent Refs" with the "Permanent Refs" option.
This means that commits only reachable from special refs like `refs/pulls/123` are no longer treated as "published commits". Instead, they are "unpublished", considered draft/temporary/transient, and do not send email, trigger audits, etc. If they are later merged and become an ancestor of a permanent ref, that operation publishes them.
---
**Publishing Commits**: The "Autoclose" and "Publish/Notify" behaviors from repositories have combined into a single "Publish" behavior.
When a commit becomes an ancestor of a permanent ref (often, because someone pushed it to a branch like `master`) we take various publishing actions, including:
- sending email;
- publishing a feed story;
- delivering notifications in the main menu bar of the web UI;
- running Herald rules;
- triggering audits from Owners;
- closing related tasks referenced with `Fixes Txx`; and
- closing related revisions.
Previously, some of these actions were "Autoclose" actions and some were "Publish/Notify" actions, and it was possible to run a subset of these actions on a commit. All publishing behavior is now a single "Publish" step and we either do nothing or everything.
The "Autoclose On/Off" option has been removed from repository configuration. The "Publishing On/Off" option is still supported.
The expectation is that this option is rarely useful, and mostly relevant if you need to perform a major history rewrite of an existing repository.
**Permanent Refs**: The "Autoclose Only" option in repositories is now called "Permanent Refs". The meaning has changed slightly, although in most cases the old configuration will still be the correct new configuration.
When a commit becomes an ancestor of a permanent ref, we publish it and take all the publishing actions described above. Until then, we do not take any actions, and the commit is marked as "Unpublished" in the web UI.
By default, all branches are permanent refs. Other refs (tags, notes, and arbitrary other refs) are not. This means that, by default:
- Pusing a commit to any branch will publish it.
- Pushing a commit only to a tag or ref (including `refs/pulls/...` or `refs/changes/...`) will not publish it. The commit will be available in the web UI but will not send email, notifications, trigger audits, etc.
**Track Only**: The "Track Only" option in repositories has been deprecated.
This option was primarily used to disable both "Autoclose" and "Publish" behavior, or disable "Publish" behavior for non-branch refs. As a side effect, it also disabled import/UI behavior, but this is generally undesirable.
Essentially all use cases should be obsoleted by the new publishing behavior and the "Permanent Ref" rules.
In most case, "Track Only" rules should be turned into "Permanent Ref" rules. In a small number of cases, turning them into "Fetch Only" rules instead may be appropriate (see below).
This option will be removed in some distant future version of Phabricator.
**Fetch Only**: A new "Fetch Only" option can apply limits to which refs are fetched when observing repositories.
By default, all refs are fetched. If you only want to fetch particular refs (like `refs/heads/master`) or patterns (like `refs/heads/*` and `refs/tags/*`), you can now specify what to fetch.
This is an advanced option, and most installs should not need to configure it.
This is primarily intended to reduce operational overhead in environments where a monorepo has accumulated tens of thousands of `tmp-bugfix-123-do-not-delete` branches after years of creative use under a regime of "git push = save changes".
**Repository API**: The repository branch rulesets ("Fetch Only", "Permanent Refs") are now available via Conduit on `diffusion.repository.search`.
---
Broadly, the default configuration for repositories should now align with desired behavior in almost all cases. Particularly, these scenarios now have better behavior:
- You observe a repository on GitHub.
- Before: Weird behavior with `refs/pulls/...`.
- After: These commits will be fetched and imported into the web UI, but will remain "Unpublished".
- You observe a repository used with Gerrit.
- Before: Weird behavior with `refs/changes/...`.
- After: These commits will be fetched and imported into the web UI, but will remain "Unpublished".
The only common exception (where the default configuration may not work well without changes) is using "git push" to mean "save changes". If your users routinely push branches named `tmp-bugfix-123-do-not-delete` to save their work, you should set "Permanent Refs" to the list of real branches (`master`, `stable`, ...).
Security
========
- //No notes in this period.//
Migrations
==========
| Migration | Risk | Duration | Notes |
|-----------|------|----------|-------|
| 20190416.chart.01.storage.sql | | 18 ms |
//"Duration" is the duration for this install, and may not be representative.//
Upgrading / Compatibility
=========================
IMPORTANT: Finish importing any outstanding repositories before upgrading through this release. If you do not, some commits may become stranded because of parsing pipeline changes. They can be fixed manually with `bin/repository reparse`, but upgrading with an empty daemon queue is likely to be more convenient.
- The "Commit is on autoclose branch" rule in Herald has been deprecated. Since both behaviors (autoclose and Herald) are now part of the "publish" step, commits which Herald is triggering on are always ancestors of a permanent ref, so this condition is always true. It is no longer possible to run Herald rules or trigger publishing actions on "unpublished commits".
- The `DifferentialRevision::TABLE_COMMIT` table no longer has readers or writers. This has been obsoleted by edges. Some related APIs have changed slightly. This would only impact custom code.
- The `--force-autoclose` flag has been removed from `bin/repository reparse`, because the "Autoclose" step no longer exists.
- The `Owners` and `Herald` workers have been merged into a new `Publish` worker.
Charts
======
these may need a little more work
{F6406404}
Minor
=====
- [{icon tint, color=sky}] Git repository working copies now have their `HEAD` symbolic ref set to the configured default branch, so cloning from repositories with no `master` should no longer raise a warning.
- [{icon tint, color=sky}] When performing transaction edits, we now acquire a read lock sooner. This is aimed at fixing a race condition during revision closure, but it is possible this change has far-reaching uintended consequences and makes things worse or better.
Internal
========
- Git SSH workflows now have a developer-facing protocol log.
- [{icon tint, color=sky}] With prototypes enabled, the `git upload-pack` wire protocol is now parsed, examined, and then flattened back into wire bytes. The current expected effect of this proxy is to leave the wire protocol completely unmodified. In the future, we will rewrite the protocol.
- Fixed an issue with notification pagination.
- Fixed an issue with before/after cursors in "feed.query".
- [{icon tint, color=sky}] Fixed an issue when rendering revision close stories referencing commits with no identities.
//The [{icon tint, color=sky}] icon indicates a change backed by support mana.//