See T9530.

@avivey: I'm somewhat interested in this if you have any tips for getting it working locally I would like to try it out and see if I can contribute anything towards a finished extension.

I've made some progress in the direction of this task in D16981 and D17020, but I've since then more-or-less lost the external pressure to implement this. I might get around to completing this eventually, but I might not.
The code in those diffs is mostly usable, but it does require some amount of local extensions to be implemented. If anyone is interested in trying it out (Or even taking over the changes), I can instruct you on how to do it locally and what's missing.

In T9530#177353, @hach-que wrote:

So I was thinking about software components recently and one of the issues I've had with both Jenkins and Harbormaster is that builds of one repository aren't aware of the builds from another repository. This is a common scenario in the software I build:

• DiffusionCommitQuery has had the "good" version for a while.
• We're nuking Releeph at some point.

@hach-que what you describe is being used by OpenStack (a cloud management system) for their CI. They wrote an adhoc software named Zuul and the feature you describe match the description at http://docs.openstack.org/infra/zuul/gating.html It is using Gerrit (a code review tool by Google for Android) as a source. So you are not alone :-]

One thing that happened locally wrt "Product Lines" and 40 apps:

• RelMan wants to think about the 40 apps going out at the same time as a single thing, even if they have slightly different code changes.

For instance, they want to cut them all at the same time, and deploy them all to the staging environment/prod in one go, etc.
ATM, that means that we have a single Release with lots of repos in it, but that might one day grow into a "Meta-Release"/"Release Bag"/"Train", which is basically a collection of releases that are managed together.

So I was thinking about software components recently and one of the issues I've had with both Jenkins and Harbormaster is that builds of one repository aren't aware of the builds from another repository. This is a common scenario in the software I build:

FWIW, at the WMF we make releases that involve hundreds of repositories: one for mediawiki, plus one for each mediawiki extension that we host. I don't think it is an ideal situation, and it causes me all kinds of grief, but it's the current state of affairs. So there is at least one potential use case for a release that encompasses a snapshot of multiple repos.

The future of these pipelines in the upstream is server-side, not client-side. See T9530.

Not sure if any of this is relevant to T8297, but everyone loves walls of text!

@hach-que - I'm getting ready to public-ize this task (After updating the description).

Yeah, that seems reasonable to me. You can already "Close Branch" today which is effectively the same action as "Freeze Release". I'm broadly comfortable with moving Harbormaster in the direction of having richer application awareness and interactions, although we'll have to think a bit about what happens when you "Freeze Release" in a build plan and run it on a commit (does it fail? get skipped? configurable?).

"Binary" style releases might actually not be as immutable as I'm hoping; A Release Candidate might start it's life as a cherry-pick style release, and then be frozen at some point. If we're building binaries each time a new cherry-pick is picked (To test in Staging, e.g.), we might call them all "3.11 RC3", and when finalizing, build a new one as "3.11".

• Go to a Branch/Release page.
  • Click the "New Pull Request" button.
  • That goes into the queue for the Branch/Release.
  • Whoever owns the Branch/Release can approve/reject it.
  • That's the end of the workflow today since Harbormaster didn't exist and none of T182 was planned. Last I knew, Facebook completed the rest of the workflow with custom arc do-a-bunch-of-git-stuff extensions.

(The pull requests are just useless outside of the Facebook workflow because they can't merge and the "you can do hundreds of them really quickly" aspect isn't useful at less-than-Facebook scales.)

"Pull Requests" are the existing "Pull Requests" in Releeph. They're literally just pull requests. Releeph today is like 90% about implementing pull requests and then 10% about surfacing pertinent details about those requests prominently so chuckr and peers can bulk process hundreds of them per day.

Specifically, here are three workflows with different levels of mutability that I'd like to support:

The "sort-of-like-github-pr" flow of master is essentially a hook for master being updated? Or more "pull request" where "deploy" means "merge to master and close this"?

I'm thinking of "Release Plan" as a more generic Product:

• Instructions on how to cut
• Instructions on which HM build(s) to run when
• List the expected artifacts

Release will be as immutable as possible

Artifacts: Either as Files or Phragments, they can be:

• Attached to a Release with some flag / slot (A Release expects some specific artifacts)
• Trigger a build for "validation" (if uploaded from outside the system)
• We can feed them via the HM Build, as in "expect the file to be somewhere, then create a HM Artifact". This sounds a big convoluted.

So, here's what I understand:

As an engineer at Facebook, if you saw "chuckr mentioned you in IRC", pants were ruined.

A culvert is just a big drainpipe.

("Pipeline" and "Conveyor" both sound like ETL to me. didn't get "Culvert" and "Chuckr").

Chuckr would be my vote

The name "Pipeline" brings "Data Pipeline" to mind for me, possibly because AWS has a product called "AWS Data Pipeline", although it looks like no one else particularly likes "Releeph" either.

Keep in mind those test releases will be based off diffs, not commits in that model, so we almost certainly can't re-use any of the built artifacts since they aren't integrated.

OK, that makes sense to me.

Well, it is essentially releasing into a non-production environment. We may then want to promote the artifact from the test environment to production.

@joshuaspence: I have practically the same desire, but I think HM and Drydock are moving to answer this need ("Build be a complex environment based on this diff").
I'm not sure how this fits into the "Release" and "Workflow" use-cases though?

I'll fix the header though, since I missed that grep.

Fair enough, thanks for looking :)

This isn't a usable application, at least that I'm aware of.

https://secure.phabricator.com/book/phabricator/article/prototypes/

After an upgrade of phabricator (from rPad7760061d4f83d5607128a9565e544cfbb8e2bb to rP3937d34) and verifying that all PHP process were restarted, the error at /releeph/branch/1/ points somewhere else:

Restart Apache or PHP-FPM, according to the upgrade guide:

Specifically rPae81f86a67b33 cleaned up Releeph. I would verify your update to Phabricator went correctly (and restarted PHP).

What is the full stack trace? There is nothing obvious to me in the code that could case this.

In T2714#119487, @Yomi wrote:

Totally off-topic, but how do you pronounce Releeph?

Totally off-topic, but how do you pronounce Releeph?