Closed Bug 1935142 Opened 1 year ago Closed 10 months ago

New phabricator webhook for code review

Categories

(Conduit :: Phabricator, task)

Product:
Conduit
Component:
Phabricator
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bastien, Assigned: dkl)

References

(
URL
)

Details

Attachments

(2 files)

image.png
129.07 KB, image/png
Details
Bad patch to test new code review trigger
48 bytes, text/x-phabricator-request
Details | Review

Hello,

I'm working on the code-review project running on Firefox CI & Heroku (here is a short summary of what I'm trying to build currently).

We have been using a Phabricator webhook upon new Diffs for a few years, targeting https://code-review-events-production.herokuapp.com/ to start new CI builds from try.

I'm working on replacing the Heroku events system by a Taskcluster task (one task per diff), that would be trigerred by Phabricator using the triggerHookWithToken API call.

Could you create on Phabricator production (to get real diffs) a new webhook configured as:

  • POST method with JSON payload (which seems to be the supported format)
  • on every new Phabricator Diff
  • url is https://firefox-ci-tc.services.mozilla.com/api/hooks/v1/hooks/project-relman/code-review-testing/trigger/<REDACTED_TOKEN>
  • I'm not sure what the JSON payload would contain for that specific case: if you can provide an example, that would be great !

The url is secured with a token <REDACTED_TOKEN> that I can provide through email+GPG encrypted message (or whatever secure mean you prefer).

First, the current feature that sends data for new diffs is a Harbormaster Build Plan https://phabricator.services.mozilla.com/harbormaster/plan/4 and not a Webhook. Currently we are not utilizing webhooks for anything in Phabricator. We can use a webhook if you prefer to use that but it does not wait for returned status like a build plan does. If you do not need that then it should be fine. The webhook feature, we would have to put the token in the URL so we would have to make the webhook private and not viewable by public.

I don't have any samples of the data that a webhooks sends in the body other than what is in the docs. I am sure I could set up a test API endpoint somewhere and have Phabricator send an event to see what the data looks like.

Assignee: nobody → dkl
Status: NEW → ASSIGNED

Hello David,

Thanks a lot for the quick reply !

I totally forgot about the build plan in Harbormaster. Webhooks are not required for our use.

I see that the current step is a HTTP request but without any payload. Is it possible to add an extra step with a JSON payload such as :

{
  "diff": "${buildable.diff}",
  "repo": "${repository.phid}",
  "build": "${build.id}",
  "target": "${target.phid}",
  "revision": "${buildable.revision}"
}

(In reply to Bastien Abadie [:bastien] from comment #2)

Hello David,

Thanks a lot for the quick reply !

I totally forgot about the build plan in Harbormaster. Webhooks are not required for our use.

I see that the current step is a HTTP request but without any payload. Is it possible to add an extra step with a JSON payload such as :

{
  "diff": "${buildable.diff}",
  "repo": "${repository.phid}",
  "build": "${build.id}",
  "target": "${target.phid}",
  "revision": "${buildable.revision}"
}

Unfortunately, after looking at the code, it does not seem possible to include a JSON payload in the request body. Seems like it only allows for passing query parameters in the URI of the POST request.

https://github.com/mozilla-conduit/phabricator/blob/master/src/applications/harbormaster/step/HarbormasterHTTPRequestBuildStepImplementation.php#L41-L87

Upstream considered but never implemented it https://secure.phabricator.com/T9608

If you care unable to work with the variable values in the URI using POST or GET, then we would need to create a custom build step similar to the CircleCI step just for your purpose. This would take more time and we would need to prioritize it with limited resources.

Let me know

Flags: needinfo?(abadie)

We do require POST request + JSON payload to use triggerHookWithToken in Taskcluster API:

The payload must be a JSON object, and is used as the context for a JSON-e rendering of the hook's task template, as described in "Firing Hooks".

The query parameters would not be accessible from the Taskcluster task.

I understand that building a custom build step would be more work on your side, so can we try a webhook as it should match Taskcluster requirements ?

Flags: needinfo?(abadie) → needinfo?(dkl)

(In reply to Bastien Abadie [:bastien] from comment #4)

We do require POST request + JSON payload to use triggerHookWithToken in Taskcluster API:

The payload must be a JSON object, and is used as the context for a JSON-e rendering of the hook's task template, as described in "Firing Hooks".

The query parameters would not be accessible from the Taskcluster task.

I understand that building a custom build step would be more work on your side, so can we try a webhook as it should match Taskcluster requirements ?

Sure. Let me try some testing to see if it will be secure enough.

Flags: needinfo?(dkl)

Ok so I did some testing and here is what I found out.

  1. I tested against a test endpoint I set up at https://webhook.site.
  2. I created a webhook on phabricator-dev.allizom.org and made it viewable and editable only by administrators.
  3. I created a test global Herald Rule that triggers when a new revision is created and then calls the new webhook.
  4. I then created a test revision to make sure the webhook fired correctly.
  5. On webhook.site, I saw that the JSON data from phabricator-dev was received properly.
  6. I looked at the Herald transcript for the new revision, and even though it shows a webhook was triggered, it would not allow anyone to see the details of the webhook unless you are an administrator.
  7. The data received at website.hook from phabricator-dev was exactly this:
{
  "object": {
    "type": "DREV",
    "phid": "PHID-DREV-cljdgxaey4cxvxb4knjp"
  },
  "triggers": [
    {
      "phid": "PHID-HRUL-y4g3jm6qrqarufzfohfq"
    }
  ],
  "action": {
    "test": false,
    "silent": false,
    "secure": true,
    "epoch": 1733442143
  },
  "transactions": [
    {
      "phid": "PHID-XACT-DREV-uxsvjvneur37nue"
    },
    {
      "phid": "PHID-XACT-DREV-qulb5hkuij2ugz6"
    },
    {
      "phid": "PHID-XACT-DREV-hsygmkod3scvfxo"
    },
    {
      "phid": "PHID-XACT-DREV-6vhe4gqkpmhlhvy"
    },
    {
      "phid": "PHID-XACT-DREV-hk5zrs54cw7lr3w"
    },
    {
      "phid": "PHID-XACT-DREV-ublcnlitaq5sh3x"
    },
    {
      "phid": "PHID-XACT-DREV-tyevaf5wulxmn7y"
    },
    {
      "phid": "PHID-XACT-DREV-nmx7mfwyao7iul2"
    },
    {
      "phid": "PHID-XACT-DREV-pal453i7g2iglpq"
    },
    {
      "phid": "PHID-XACT-DREV-62sdvz3h2ii4jkj"
    },
    {
      "phid": "PHID-XACT-DREV-bw346binj5r4v6h"
    },
    {
      "phid": "PHID-XACT-DREV-pnra5n5toc7cdz4"
    }
  ]
}

So webhooks will work for your purpose with the downside that we cannot alter the JSON data that is sent. You would need to use the conduit API and the new revision phid (PHID-DREV-cljdgxaey4cxvxb4knjp) to find out any details about the revision such as the diff phid and other details which is all doable. You would just need to create an account in phabricator and an API key to use to query the revision details. But from testing, at least I know that is we put the taskcluster token in the URI of the webhook, noone will be able to see it except for administrators.

Thoughts?

Flags: needinfo?(abadie)

Wow, thanks a lot for that work, this looks great.

I should be able to use that kind of JSON payload in Taskcluster hooks pre-processing.

Could you create the same thing but with a Herald rule on Differential Diffs instead of revisions ? This is what we are looking for in the code-review bot.
Then using DIff + Phabricator conduit API I can lookup the Harbormaster buildable to publish updates there.

Flags: needinfo?(abadie)

(In reply to Bastien Abadie [:bastien] from comment #7)

Wow, thanks a lot for that work, this looks great.

I should be able to use that kind of JSON payload in Taskcluster hooks pre-processing.

Could you create the same thing but with a Herald rule on Differential Diffs instead of revisions ? This is what we are looking for in the code-review bot.
Then using DIff + Phabricator conduit API I can lookup the Harbormaster buildable to publish updates there.

Unfortunately Herald does not have an option to fire a webhook based on a diff, only revisions, etc. So you would need to call:

Request differential.diff.search

{"constraints": {"revisionPHIDs": ["PHID-DREV-cljdgxaey4cxvxb4knjp"]}}

Response

{
  "result": {
    "data": [
      {
        "id": 5812,
        "type": "DIFF",
        "phid": "PHID-DIFF-spd5gzxvepmuogvepm5a",
        "fields": {
          "revisionPHID": "PHID-DREV-cljdgxaey4cxvxb4knjp",
          "authorPHID": "PHID-USER-4wigy3sh5fc5t74vapwm",
          "repositoryPHID": null,
          "refs": [],
          "dateCreated": 1733441703,
          "dateModified": 1733442142,
          "policy": {
            "view": "public"
          }
        },
        "attachments": {}
      }
    ],
    "maps": {},
    "query": {
      "queryKey": null
    },
    "cursor": {
      "limit": 100,
      "after": null,
      "before": null,
      "order": null
    }
  },
  "error_code": null,
  "error_info": null
}

Looked at https://github.com/mozilla/libmozevent/blob/master/libmozevent/phabricator.py#L24-L27 and it shows that it is getting the values from the query string.

Is the herald rule triggered when a new diff is published on the revision though ? Even if we do not have direct access to the DIff ID/PHID, we need a trigger for every new diff.

Looked at https://github.com/mozilla/libmozevent/blob/master/libmozevent/phabricator.py#L24-L27 and it shows that it is getting the values from the query string.

Absolutely, that's the current implementation I'm working on replacing. Taskcluster trigger hook with a token does not pass along the query string parameters. The current Herald rule trigger is received by a custom webserver which uses the query string parameters.

I'm working on support for triggerHookWithToken on the code-review testing hook in fxci-config.

Flags: needinfo?(dkl)

(In reply to Bastien Abadie [:bastien] from comment #10)

Is the herald rule triggered when a new diff is published on the revision though ? Even if we do not have direct access to the DIff ID/PHID, we need a trigger for every new diff.

Ok the only way to make this work is to follow the suggested in the User Documention for webhooks [1] and to query the API after getting the initial webhook when a revision changes, to find out what the transactions were. So basically we set up a differential revision herald rule that triggers when any changes are made. The rule then sends the webhook each time to your endpoint. The webhook data will include a list of transactions (PHID-XACT-DREV-*). Then your code will need to use the transaction.search conduit API endpoint [2] to get additional information about the transactions. Your code will then look for any transaction where there is a diff change (example below) and get the new diff PHID. Then you can make another call to the conduit API to get the full details of the diff using differential.getrawdiff [3].

{                                                                                                                                                                                                                                                             
  "result": {                                                                                                                                                                                                                                                 
    "data": [                                                                                                                                                                                                                                                 
      {
        "id": 236999,
        "phid": "PHID-XACT-DREV-ilhpubx4fzqthzy",
        "type": "comment",
        "authorPHID": "PHID-USER-4wigy3sh5fc5t74vapwm",
        "objectPHID": "PHID-DREV-syiyscpw7zbvu6c5axyg",
        "dateCreated": 1733777349,
        "dateModified": 1733777349,
        "groupID": "qd36d4dwwjuifxqzlxxvuam2walwzjat",
        "comments": [
          {
            "id": 21272,
            "phid": "PHID-XCMT-n27bnx5uu5nogn4refti",
            "version": 1,
            "authorPHID": "PHID-USER-4wigy3sh5fc5t74vapwm",
            "dateCreated": 1733777349,
            "dateModified": 1733777349,
            "removed": false,
            "content": {
              "raw": "Test"
            }
          }
        ],
        "fields": {}
      },
      {
        "id": 236998,
        "phid": "PHID-XACT-DREV-h6lca2lnla4l5bc",
        "type": "update",
        "authorPHID": "PHID-USER-4wigy3sh5fc5t74vapwm",
        "objectPHID": "PHID-DREV-syiyscpw7zbvu6c5axyg",
        "dateCreated": 1733777349,
        "dateModified": 1733777349,
        "groupID": "qd36d4dwwjuifxqzlxxvuam2walwzjat",
        "comments": [],
        "fields": {
          "old": "PHID-DIFF-okg32awaq7icxcb42x7r",
          "new": "PHID-DIFF-fvkaposhkoodd266lf2c",
          "commitPHIDs": []
        }
      }
    ],
    "cursor": {
      "limit": 100,
      "after": null,
      "before": null
    }
  },
  "error_code": null,
  "error_info": null
}

[1] https://phabricator-dev.allizom.org/book/phabricator/article/webhooks
[2] https://phabricator-dev.allizom.org/conduit/method/transaction.search
[3] https://phabricator-dev.allizom.org/conduit/method/differential.getrawdiff

Flags: needinfo?(dkl)

Thank you for the update, I'll modify the fxci-config PR to take into account the transactions from the webhook.

(In reply to Bastien Abadie [:bastien] from comment #12)

Thank you for the update, I'll modify the fxci-config PR to take into account the transactions from the webhook.

Let me know when you will need the Herald rule setup. We can also test this on phabricator-dev.allizom.org if needed.

The code-review-testing hook was just updated to support that payload.
I was able to trigger a task using your JSON payload and the trigger token.

I'll implement a new mode for the bot tommorow to interact with the payload and check Phabricator, I'll ping you here when it's ready to receive triggers from Phabricator.

Setting needinfo to let me know when you are ready for me to set up the webhook in production, etc.

Flags: needinfo?(abadie)

I'm working on the actual bot implementation but this will probably not be reviewed nor deployed until early January. I'll keep you posted once it's ready.

Hello David,

We just deployed a version of the bot supporting the trigger from Herald rule on that Taskcluster Hook.

Could you setup a new Herald rule (and webhook) on phabricator-dev to trigger a POST request on https://firefox-ci-tc.services.mozilla.com/api/hooks/v1/hooks/project-relman/code-review-testing/trigger/<REDACTED_TOKEN> for new revisions ?

I can provide the token by whatever secure mean you prefer.

FYI I'm currently unable to log onto bugzilla-dev (and so on phabricator-dev). I just requested help from bmo-mods to recover my account on bugzilla-dev.

Flags: needinfo?(abadie) → needinfo?(dkl)

Ok. Webhook and Herald rule created on phabricator-dev for testing.
https://phabricator-dev.allizom.org/H15

Flags: needinfo?(dkl)

Thanks a lot, that worked ! I just got a task triggered from a new revision on phabricator-dev

The revision lacks a Harbormaster build target. There is a buildable & build that I'm able to lookup, but without a build target I'll be unable to test the message publication.

Could you trigger the build target creation automatically ? I don't really know how that works in Phabricator for that part...

Flags: needinfo?(dkl)

(In reply to Bastien Abadie [:bastien] from comment #19)

Thanks a lot, that worked ! I just got a task triggered from a new revision on phabricator-dev

The revision lacks a Harbormaster build target. There is a buildable & build that I'm able to lookup, but without a build target I'll be unable to test the message publication.

Could you trigger the build target creation automatically ? I don't really know how that works in Phabricator for that part...

Webhooks are different than Harbormaster builds. They do not create a buildable or build to refer back to. Webhooks are one off API calls that are sent out when a Herald rule matches certain conditions. If you want the buildables to be created we will have to convert over to a build plan which we decided earlier wouldn't work for the way the taskcluster code was written.

Flags: needinfo?(dkl)

Thank you David for the explanation, it's much clearer now.

This next paragraph is more for :marco & :aryx :

We have now 2 options:

  1. use a Phabricator webhook to trigger Taskcluster Hook with token, but we do not have a Harbormaster build target to update

    • the bot support this input for the analysis part
    • but it currently requires a build target to run publication
    • without a build target, we cannot post messages on the intergace top level, we'll be limited to comments.

  2. use a Phabricator build plan that will provide a Harbormaster build target, but :

    • we cannot send any JSON Payload (not supported by Phabricator - see this comment above) through Harbormaster build steps
    • taskcluster does not support query parameters in the URL in the triggerHookWithToken API endpoint
    • this will require a small update on the bot analysis code, but will reduce in complexity the Revision initial build

I think it would be better to stick with a Pahbricator build plan, as we have been using that for the past years, and do not want to change the messaging targeted at developers.
We need to find a way to trigger the Taskcluster Hook without a JSON payload & using query parameters:

  • building a tiny web service that receives the HTTP query from Phabricator and converts it for Taskcluster
  • do the same but using an existing service like ifttt
  • support URL query parameters in triggerHookWithToken

I filed a Github issue about that last step to get Taskcluster developers input.

I made a Taskcluster patch to support URL query parameters when triggering hooks. It just got merged, and will be deployed on Firefox CI on February 6th.

We'll then be able to use a Harbormaster plan instead of the webhook.

I'll update the Taskcluster hook definition to use the existing query parameters (with Harbormaster build target ID) and the bot code.

Does that sound OK to you David ?

Flags: needinfo?(dkl)

(In reply to Bastien Abadie [:bastien] from comment #22)

I made a Taskcluster patch to support URL query parameters when triggering hooks. It just got merged, and will be deployed on Firefox CI on February 6th.

We'll then be able to use a Harbormaster plan instead of the webhook.

I'll update the Taskcluster hook definition to use the existing query parameters (with Harbormaster build target ID) and the bot code.

Does that sound OK to you David ?

Sounds great to me. Just ping me when it is time to setup the build plan.

Flags: needinfo?(dkl)
Depends on: 1944522

We should be able to test the Harbormaster build plan with HTTP Build step if my latest patch is available on phabricator-dev.

Could you edit the existing build step with this configuration:

  • POST query
  • Url https://firefox-ci-tc.services.mozilla.com/api/hooks/v1/hooks/project-relman/code-review-testing/trigger/<REDACTED_TOKEN> (same url & token as the previous webhook)
  • Content-type must be set to application/json
  • HTTP Body must be set to {"build_target_phid": "${target.phid}"}

You'll also need to delete the webhook.

Finally, the build plan should be executed upon new diffs - same trigger as the one on prod.

Thanks again !

Flags: needinfo?(dkl)

(In reply to Bastien Abadie [:bastien] from comment #24)

We should be able to test the Harbormaster build plan with HTTP Build step if my latest patch is available on phabricator-dev.

Could you edit the existing build step with this configuration:

  • POST query
  • Url https://firefox-ci-tc.services.mozilla.com/api/hooks/v1/hooks/project-relman/code-review-testing/trigger/<REDACTED_TOKEN> (same url & token as the previous webhook)
  • Content-type must be set to application/json
  • HTTP Body must be set to {"build_target_phid": "${target.phid}"}

You'll also need to delete the webhook.

Finally, the build plan should be executed upon new diffs - same trigger as the one on prod.

Thanks again !

Ok all set up on phabricator-dev. All changes are also live on production to support setting this up there once everything looks OK.

Flags: needinfo?(dkl)

I created a new test revision, a buildable was started, but without any steps.

I think the build plan n°5 is somehow enabled instead of the build plan n°7 which has the correct step.

Flags: needinfo?(dkl)

(In reply to Bastien Abadie [:bastien] from comment #26)

I created a new test revision, a buildable was started, but without any steps.

I think the build plan n°5 is somehow enabled instead of the build plan n°7 which has the correct step.

Ok try again. I disabled build plan 5 and I fixed the Herald rule that runs build plan 7 to look for the correct repo. Should work now according to the test console.

Flags: needinfo?(dkl)

I published an update on the same revision, a build using plan 7 started but the HTTP request failed: there are no triggered tasks on Taskcluster, and we should view a JSON response with a task ID on that page.

Do you have more logs than what's displayed on that page ?

FWIW I tried the Taskcluster trigger url with curl, and it still works as expected.

I published a new revision and got the same failure on HTTP build step.

Flags: needinfo?(dkl)

Hey sorry for all of the delay. I set up a new harbormaster build plan and build step that sends the same type of data to webhook.site and it looks OK from my point of view.

https://phabricator-dev.allizom.org/harbormaster/step/view/10/
https://phabricator-dev.allizom.org/D3732

Wish we could see the output on the taskcluster side as Phabricator gives no indication of what the error is. Just http 3 whatever that means

Flags: needinfo?(dkl)
Attached image image.png —

Thanks for looking into this issue.

:yarik on the Taskcluster team looked into the Taskcluster backend logs around the time when build 8561 was done, and no requests hit the triggerHookWithToken API endpoint.

I also tested from my local Phabricator instance with the exact same configuration as that build step, and I was able to trigger a task on Taskcluster.

Could there be something blocking requests from Phabricator-dev towards firefox-ci ?
I don't know how to work around this...

Flags: needinfo?(dkl)

(In reply to Bastien Abadie [:bastien] from comment #32)

Thanks for looking into this issue.

:yarik on the Taskcluster team looked into the Taskcluster backend logs around the time when build 8561 was done, and no requests hit the triggerHookWithToken API endpoint.

I also tested from my local Phabricator instance with the exact same configuration as that build step, and I was able to trigger a task on Taskcluster.

Could there be something blocking requests from Phabricator-dev towards firefox-ci ?
I don't know how to work around this...

I will talk to emaydeck of cloudops to see if something funky is going on with networking between the clusters.

Flags: needinfo?(dkl)

(In reply to David Lawrence [:dkl] from comment #33)

I will talk to emaydeck of cloudops to see if something funky is going on with networking between the clusters.

Latest replies from emaydeck about this issue:

He was able to connect via nc on the webhead box in dev:

[emaydeck@ip-172-31-61-118 ~]$ nc -zv -w 1 firefox-ci-tc.services.mozilla.com 443
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 35.190.5.182:443.
Ncat: 0 bytes sent, 0 bytes received in 0.06 seconds.

[emaydeck@ip-172-31-62-139 ~]$ nc -zv -w 1 firefox-ci-tc.services.mozilla.com 443
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 35.190.5.182:443.
Ncat: 0 bytes sent, 0 bytes received in 0.17 seconds.
[emaydeck@ip-172-31-62-139 ~]$ curl https://firefox-ci-tc.services.mozilla.com
<!doctype html><html lang="en"><head><meta charset="utf-8"/><meta name="viewport" content="width=device-width,initial-scale=1"><meta name="viewport" content="width=device-width,initial-scale=1"><link href="/assets/10.01228d8d.css" rel="stylesheet"><link href="/assets/13.3f2cba5a.css" rel="stylesheet"></head><body><script src="/static/env.js"></script><div id="root"></div><script src="/assets/runtime.1f8830aa.js"></script><script src="/assets/10.19f34629.js"></script><script src="/assets/13.ce8dc296.js"></script><script src="/assets/index.ba40cd0b.js"></script></body></html>[emaydeck@ip-172-31-62-139 ~]$ ^C
[emaydeck@ip-172-31-62-139 ~]$

emaydeck: yeah, i would have been shocked if there were some networking restriction like that considering the fxci endpoint is public

So it does not seem to be a networking issue between Phabricator and taskcluster.

I'm trying to find ways to troubleshoot this issue, as I'm completely blocked on the overall project without that part.

  • Could you provide me the docker image currently deployed on phabricator-dev so I can test locally using the exact image ?
  • Is there a way to test this configuration on phabricator in production ? Same build step, but limited to a single revision (or user) ?
  • Can I get edit access for habormaster build plans on phabricator-dev ?
Flags: needinfo?(dkl)

(In reply to Bastien Abadie [:bastien] from comment #35)

I'm trying to find ways to troubleshoot this issue, as I'm completely blocked on the overall project without that part.

  • Could you provide me the docker image currently deployed on phabricator-dev so I can test locally using the exact image ?
  • Is there a way to test this configuration on phabricator in production ? Same build step, but limited to a single revision (or user) ?
  • Can I get edit access for habormaster build plans on phabricator-dev ?

I would be curious to see if this all worked in production as opposed to phab-dev. All of the code changes that you did are also in production so in theory it can send requests the same as dev to where ever we need to. So I am fine of course with setting this up on prod and having it run there to see if the outcome is different.

I can give you admin on phab-dev and you would then be able to create herald rules and harbmaster build plans as much as needed. Will do that today.

Flags: needinfo?(dkl)

It would be great to create a new build plan in production, with the following configuration:

  • exact same build step as on phabricator-dev (targeting the project-relman/code-review-testing hook)
  • a custom herald rule that runs on all Differential revisions but limited to my own account as author (bastien in production)

The goal is to run the code-review testing hook from phabricator production but only on my own pushes to avoid trigerring bad builds for any other developers

I was able to create a new build plan on phabricator-dev triggered by a custom herald rule for updates on my own revisions.

I then added 2 build steps to create Taskcluster tasks:

  1. on dev.alpha.taskcluster-dev.net
  2. firefox-ci-tc.services.mozilla.com

Well that worked immediately. I got Taskcluster tasks on both instances with the expected PHABRICATOR_BUILD_TARGET environment variable.

I have absolutely no idea why that worked and it does not on the initial build plan which still gets HTTP 3.

We should be able to ship a custom herald rule to test that on phabricator prod soon.

(In reply to Bastien Abadie [:bastien] from comment #38)

I was able to create a new build plan on phabricator-dev triggered by a custom herald rule for updates on my own revisions.

I then added 2 build steps to create Taskcluster tasks:

  1. on dev.alpha.taskcluster-dev.net
  2. firefox-ci-tc.services.mozilla.com

Well that worked immediately. I got Taskcluster tasks on both instances with the expected PHABRICATOR_BUILD_TARGET environment variable.

I have absolutely no idea why that worked and it does not on the initial build plan which still gets HTTP 3.

We should be able to ship a custom herald rule to test that on phabricator prod soon.

I am glad to see that you were able to get that working and I also cannot explain why the original build plan was not working. Sometimes tearing it down and starting from scratch is a fix. I can give you admin rights on prod temporarily if you want to go ahead and set everything up there and we can see if it just works.

That would be great David. I'll setup the same herald rule limited to my own account.
If that works, when we are ready to open up the feature, you would then only have to remove the limit on the herald rule.

(In reply to Bastien Abadie [:bastien] from comment #40)

That would be great David. I'll setup the same herald rule limited to my own account.
If that works, when we are ready to open up the feature, you would then only have to remove the limit on the herald rule.

Done. I will remove admin when you have completed setup.

I created a new build plan & Herald rule on phabricator prod.

After publishing a dummy patch, I got a successfull run.

David, you can now remove the admin access on my account, the testing setup is complete on prod.

(In reply to Bastien Abadie [:bastien] from comment #43)

David, you can now remove the admin access on my account, the testing setup is complete on prod.

Admin removed. What else do we need then to close this out?

Flags: needinfo?(abadie)

Thanks for all the work there, the new hook works nicely in production now.

Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Flags: needinfo?(abadie)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: