@Ekubischta if you want to continue the discussion about the GitHub→Phorge bot, feel free to continue together here:

I see that you marked this as "Work in progress." I don't know how to highlight this fact, so I'm marking this as "Request Changes" (also because some changes were requested). Sorry if this puts a red mark, but I like this proposal of infinite executions of arc patch.

Thank you to @ncollins who helped me in understanding this topic, since I was not aware of this issue before today.

I also think that having the first branch called as arcpatch-D123_ (with trailing underscore) as default could be considered a breaking change by some users. I think this can and it should be avoided.

In T15096#3967, @valerio.bozzolan wrote:

One thing that could help a lot for my survival, for example, is the creation of a small bot able to convert the GitHub/GitLab flow to the Phabricator flow - automagically.

So, if I have a repository mirrored to GitHub in read-only, people can just do a pull request, and their stuff is converted to an arc diff, without any intervention from the code contributor.

I only warn that I work on it, because I need it for some personal side-projects hosted in my personal Phabricator - and where I don't want to yell at contributors who send pull requests from elsewhere.

One thing that could help a lot for my survival, for example, is the creation of a small bot able to convert the GitHub/GitLab flow to the Phabricator flow - automagically.

This also contains an extra Bash line:

arc lint

Just a warning that I found a few bugs just by spot checking...

@avivey the one in upstream does not contain the new ISRG Root X2 CA.

I submitted D25049 for review on the 26th to address certs signed by the ISRG Root X2 root that is in the updated default.pem file.

We've picked up an updated version of the pem at https://secure.phabricator.com/D21739 - it's not the latest, but is it recent enough?

Note the ISRG Root X2 has been added here used by Lets Encrypt.

In T15096#2333, @sario528 wrote:

Allowing a user to make quick simple changes with nothing but a web browser is IMO the single best way to encourage new contributors.

In T15096#2329, @avivey wrote:

For new users, support the the magic-ref style of gerrit, but with a web-UI Wizard based next steps, where we walk her through creating/updating the right revision, maybe explain what happens to all the commits and what other users will experience. Treat this as an onboarding experience - with the expectation that full-time contributors will eventually switch to Arcanist.
Maybe upsell Arcanist at this point.

I'd point out that Gerrit was originally intended to work with a client-side tool called repo (Which also manages multi-repo code trees).
The git push ... <magic ref> is kind of a workaround for users that found having a client-side tool annoying to use :)

In T15096#2233, @speck wrote:

Thank you for these write-ups, I'll need more time to review however I noticed Evan recently started a task in the upstream where it looks like he's investigating compiling PHP to a library for use with a custom native entrypoint which would allow distributing arcanist as a single binary (he estimates ~10mb in size).
https://secure.phabricator.com/T13675

Thank you for these write-ups, I'll need more time to review however I noticed Evan recently started a task in the upstream where it looks like he's investigating compiling PHP to a library for use with a custom native entrypoint which would allow distributing arcanist as a single binary (he estimates ~10mb in size).
https://secure.phabricator.com/T13675

Definitely agree that the effort to set up arcanist isn't huge. And at my current work, it's baked into our common Dev PC setup, so it's almost zero effort. But there is an effort, and a dev/user who is just passing by to fix a typo or suggest a one-line change in some code isn't going to be willing to do that effort.

@micax: Good points and it's helpful to hear another perspective on this. From my past experience using Phabricator on a corporate team I definitely think that arcanist helped keep everyone's workflow consistent and simple.

I find this rather interesting (and a little bit weird, to some extent), because IMO the arcanist command line tool is one of the things which IMO _add_ value to Phabricator and sets it apart from it's alternatives.

Might be worth it having the linter classes inherit from a language-specific class that would handle things like environment initialization and dependency installation.

Yeah, I think we'd like to try and update arcanist to account for this with a general solution if possible and not making updates for each individual linter which might necessitate this. There's probably some general restructuring that needs to happen to account for the same odd scenario with Java and so forth.

Checking the source in Arcanist repo, it seems like none of the python linters are actually configured to use an interpreter. (If I attempt to specify one for Pylint anyway, it fails with Got unexpected parameters: interpreter)

I think that's roughly what I ended up doing in https://secure.phabricator.com/D14632 for launching separate Java linters, where java had to be configured as the "interpreter" and checkstyle.jar (or whatever) configured as the "binary" (https://secure.phabricator.com/D15067 added the ability to pass flags to the "interpreter").

Modern(ish) linters support a separate "interpreter" config - if that's set, they run $interpreter $binary $args rather then just $binary $args. Can this be utilized?

Right now,arc lint doesn't really allow for the activation of a virtual env. That's okay when I'm just running arc lint locally, because I can just activate the environment myself and run it in that environment.

Should this be the responsibility of the linter/tester and not part of Arcanist itself? Updating arcanist to handle the many different environment-dependent systems for languages would mean accounting for nearly every language like Javascript/npm, Ruby/rubyenv, etc. right?

I've left a comment on the server-side diff.

I submitted a draft revision for this. It's not quite complete yet, but anyone interested can take a look at it.

Oh my, sorry for the noise; my search-foo didn't find that.

This is a duplicate of T15051 and potentially solved with D25023