The ability to add subscribers which is now on master should solve most of these issue for people.

Sounds good to me. This is the first link that comes up (Tested in incognito) when you search for ERR_CLOSED: This revision has already been closed and the second when you search ERR_CLOSED so documenting it here may fix most peoples issues.

This should be safe to close as I think it's all user error.

Ran into this same issue today and seeing this had no resolution I went over and tried to debug what the actual cause was.

I have been trying very hard to run arcanist / pharbicator /libphutil unforked until now so I would strongly prefer not to edit any of the source code. The second issue is that this is being run as an external command since it's a drydock build step.

Sorry to be a bother on this again. Today we almost got bitten bad by this again since the unsound test returns an exit code of 1 and the failure was actually a class not being loaded because the user had not upgraded arc on the machine.

Didn't see that ticket but just read over this and that would be what I would need. I think I am also seeing a very rare edge case as the specific issue I am seeing every day or so is that git clean -ffxd fails with warning: failed to remove /something but every time I go in to look around after everything looks completely normal and then running git clean -ffxd runs successfully.

They do lose access to managing both accounts which has caused a few issues around email addresses. It looks like we could have reduced massive pain on ourselves by letting users unlink ldap accounts and instructing them to link the new account.

This is the script that we had been using to do this which looks like it aligns cleanly with your second bullet point.

In D15247#175756, @avivey wrote:

T10363 talks about an alternative approach to the problem of "Notifications"; It's not a 100% pretty, but it would work.

I'll take a look at this

I'm not sure if this is on the path to "Notify revision author when build fails/completes", it might be (Via a secondary transaction on the revision?).

I need to push up one more patch that I have sitting on my local install that will do this. I need to test it a little more first before I am confident in it though.

Anything i can do to make this attractive / more attractive to upstream?

Maybe i am understanding this wrong but it seems prior to this diff it wasn't possible to have herald pick up the status of a buildable since the only way these are currently exposed is if another application extends PhabricatorApplicationTransaction. So you would have to write a herald rule for every application separately if you wanted people to be able to trigger notifications

So i'm about to change a bunch of this since hooking into PhabricatorApplicationTransaction seems like the proper thing to do. Adding transactions to the timeline i'll split out into another diff.

Yes i should likely abstract the transactions from the herald implementation however it was not immediately apparent to me when I was writing this. However I am trying to dig up the ticket that requested transactions be added for completed builds but can't find it right now.

What is the use case since in order to perform any meaningful actions you have to go to the web UI?

• @avivey we have our own library that is loaded in when arc runs. I had an out of date version of our library which caused this to throw an error.
• The chief complaint is that arc unit for unsound tests exits with a status of one since it's indistinguishable from arc completely failing.
• A harbormaster build step is reading the exit status to determine if the test was a real failure or just the result of an unsound test not passing.

Our use case is fairly atypical unfortunately. We have builds setup to run every time a diff is pushed. These diffs run integration tests that could take anywhere from 30minutes to a few hours and we don't require them passing since it's an extra step on top of unit tests running. However in the event that a longer running test breaks after a diff is landed we want to be able to alert not only the user who broke the integration test but also a group of users who are actively maintaining them incase they need to coordinate work.

Good point. When i was testing this i hooked into the Test Consul and allowed buildables to be passed in so everything was seemingly working for me. I am guessing i need to dig a littler deeper into the harbormaster transactions to get this working properly.

I am curious about this as well or if it has been addressed some other place. It's pretty easy to manually resolve the issue most of the time however I am not sure what the proper action would be after doing this? Does phabricator expect you to arc diff after you manually resolve it?

I also found this to be an issue. I am guessing that it wasn't initially added because it needs some locking mechanics in place to make sure you are not removing a device that may currently be in use.

Anyway to get this back on track? I don't think it's in danger of going stale but it would be really nice to get this into master as it seems to have a fairly large following now.

@ninacfgarcia I believe that is correct due to the way that arc unit runs it's tests. I will have to check if that is common between other linters but you can set eslint.eslintconfig in your .arclint or .arcconfig file so it uses the config that you want.

Thanks for the feedback. Cool to see people using it before it's merged upstream.

@avivey I added a "min version" however I think that we need to add a minVersionRequired() function as that is the real intent of the code in the constructor. I don't want to have this held up because of another diff though as i'm sure the people using a version less than 1.0.0 is close to 0% as they are on 1.9.0 right now.

• Update After Review
• Fix bad rebase
• Arc Liberate
• Arc Unit Failure

@avivey I looked around for a way to set min linter version but don't see any formal way to do it. I could write some code to run the check in getDefaultBinary() but this seems messy since none of the others are currently doing it.

I'll open up a task for this right now as well as setting the minimum linter version that can be used. Thanks for the heads up I guess I should have reread the guidelines for submitting a patch as it's been a while since I started this.

@joshuaspence you aren't on the subscription list so I'm not sure if you got any notifications about update or if you are still interested in reviewing this PR.

You will want to add some tests inside https://secure.phabricator.com/diffusion/ARC/browse/master/src/lint/linter/__tests__/ to ensure future changes don't break current functionality.

@yangsu I was looking at the work you had done on this. I was mostly curious about https://github.com/coursera/arcanist/blob/master/src/lint/linter/ArcanistESLintLinter.php#L114-L129. Do you have a js file that reproduces the case you ran into that caused a need for this code?

Updated so unit tests will now pass and added comments about why the .eslintrc file was added.

Fix Unit tests.

ESLint seems to have changes the way errors/warnings are generated. I'm looking into why the output from the test file seems to have changed now.

Fix unit test issue

Updated based on review from @joshuaspence

@turadg I am going to finish this up tonight and ask for a review again.

@davidnormo unfortunately I was working on this for my job and was using it internally before we had to switch off phabricator which makes me very sad. If you would like to take over this diff please do so and see it through :) All the work should be done it just needs some attention. I think I also messed up the unit tests with a commit but if you go back one you just need to copy / paste them in.

Anyone still actively working on getting this merged into master?

I may have messed up my tests somehow they are gone now... not sure how that happened... Let me know if i need to readd them and i'll update.

@joshuaspence sorry it took so long to get around to this. I believe I have addressed all but one of your concerns. I looked into an easier way to parse the output via all the available outputs you could use but found that none of them would provide a much cleaner way of doing it. Most would require using XML and didn't give information on the severity.

• Add in the ability to set environment and config file.

Update joshuaspence comments to reflect new commit.

cleanup from initial comments

didn't mean to open this sorry.

sorry, i became super busy with work and haven't had time to work on it. I am going to make the request changes today and submit for review again.

I know you are all super busy but it would be awesome if anyone could take a quick look. Thanks a bunch.