2019 Week 17 (Very Late April)

Updated 1,798 Days AgoPublic

Actions

Summary of changes from April 17, 2019 to April 27, 2019.

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

[] 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

"Duration" is the duration for this install, and may not be representative.

Upgrading / Compatibility

• 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

Minor

• [] 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.
• [] 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.
• [] 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".
• [] Fixed an issue when rendering revision close stories referencing commits with no identities.

The [] icon indicates a change backed by support mana.