[GH-ISSUE #18] Help setting up with own builder #13

Closed
opened 2026-03-04 00:23:08 +03:00 by kerem · 3 comments
Owner

Originally created by @yacob841 on GitHub (Mar 11, 2021).
Original GitHub issue: https://github.com/SignTools/SignTools/issues/18

Hello, so I have a web host as well as a MacOS Server. I also built an automator services that listens to folder actions, so when an ipa appears in this folder (which is a mounted NAS drive), it will kick off xresign, sign the ipa and export it back into the same folder.

So from my understanding it seems like I have the CI and Signing sections completed but just need to get the IPA from the web host to the MacOS server and then have the website recognize the finished product and allow installation.

I'm trying to find out how to integrate your front end with this backend. From my understanding I mostly just need to point the uploads to upload to the same NAS folder, and get the results from there to install. Is this something that can happen or is that going to be incompatible with your service?

Originally created by @yacob841 on GitHub (Mar 11, 2021). Original GitHub issue: https://github.com/SignTools/SignTools/issues/18 Hello, so I have a web host as well as a MacOS Server. I also built an automator services that listens to folder actions, so when an ipa appears in this folder (which is a mounted NAS drive), it will kick off xresign, sign the ipa and export it back into the same folder. So from my understanding it seems like I have the CI and Signing sections completed but just need to get the IPA from the web host to the MacOS server and then have the website recognize the finished product and allow installation. I'm trying to find out how to integrate your front end with this backend. From my understanding I mostly just need to point the uploads to upload to the same NAS folder, and get the results from there to install. Is this something that can happen or is that going to be incompatible with your service?
kerem closed this issue 2026-03-04 00:23:08 +03:00
Author
Owner

@ViRb3 commented on GitHub (Mar 11, 2021):

If you want to use your own builder then you have to use the generic builder configuration in the signing service. You also need to make a simple HTTP server on your builder that will "speak" the same protocol as the generic configuration.

As described in the configuration guide, the requirements are the following:

  # use this if you have an unsupported builder
  generic:
    enabled: false
    status_url: http://localhost:1234/status
    trigger_url: http://localhost:1234/trigger
    secrets_url: http://localhost:1234/secrets
    trigger_body: hello
    headers:
      Authorization: Token YOUR_TOKEN
    attempt_http2: true

The code in the service that will interact with your builder is here.

There are three endpoints that you need to expose and handle in your HTTP server:

secrets_url

First you need an endpoint that will take a HTTP POST with the following form values:

  • SECRET_URL=...
  • SECRET_KEY=...

The endpoint should be written under secrets_url in the config above.

SECRET_URL is the URL of your service. This is where the builder will ask for any signing jobs, and this is where the signed apps will be uploaded.
SECRET_KEY is an authorization key that has to be used when talking to your service. Otherwise everybody could upload signed apps and mess with your signing service.

When your builder takes these variables, it should save them somewhere. They must be exported for each signing job, otherwise the signing script won't know how to talk to the service.

status_url

Next you have status_url. That's not really necessary, it is just a link that will be open when you click on "Status" in the web ui while an app is being signed.

trigger_url

Finally you have trigger_url. This endpoint will be called by the service every time there's a new app waiting to be signed. Your builder should just run the signing script in ios-signer-ci with the secrets you received before. The script will do the rest - fetch a signing job from the service, perform the signing, then upload the signed app.

trigger_body, headers and attempt_http2 are optional, you can use them to configure the communication with your builder, based on how you implemented the HTTP server.

I hope I covered all points in the process. Please let me know how it goes and if you have any issues. The generic builder protocol is very new, and I haven't used it myself, so I am happy to amend it if you have any problems. My only concern is the fact that the script makes no attempt to clean up after itself, which is fine for CI builders as the environment is destroyed afterwards. As I said, I am happy to make improvements if that's an issue. Good luck!

<!-- gh-comment-id:797099457 --> @ViRb3 commented on GitHub (Mar 11, 2021): If you want to use your own builder then you have to use the `generic` builder configuration in the signing service. You also need to make a simple HTTP server on your builder that will "speak" the same protocol as the `generic` configuration. As described in the [configuration guide](https://github.com/SignTools/ios-signer-service/blob/master/INSTALL.md#21-configuration-file), the requirements are the following: ```yaml # use this if you have an unsupported builder generic: enabled: false status_url: http://localhost:1234/status trigger_url: http://localhost:1234/trigger secrets_url: http://localhost:1234/secrets trigger_body: hello headers: Authorization: Token YOUR_TOKEN attempt_http2: true ``` The code in the service that will interact with your builder is [here](https://github.com/SignTools/ios-signer-service/blob/master/src/builders/generic.go). There are three endpoints that you need to expose and handle in your HTTP server: ### secrets_url First you need an endpoint that will take a HTTP POST with the following form values: - SECRET_URL=... - SECRET_KEY=... The endpoint should be written under `secrets_url` in the config above. `SECRET_URL` is the URL of your service. This is where the builder will ask for any signing jobs, and this is where the signed apps will be uploaded. `SECRET_KEY` is an authorization key that has to be used when talking to your service. Otherwise everybody could upload signed apps and mess with your signing service. When your builder takes these variables, it should save them somewhere. They must be exported for each signing job, otherwise the signing script won't know how to talk to the service. ### status_url Next you have `status_url`. That's not really necessary, it is just a link that will be open when you click on "Status" in the web ui while an app is being signed. ### trigger_url Finally you have `trigger_url`. This endpoint will be called by the service every time there's a new app waiting to be signed. Your builder should just run the signing script in [ios-signer-ci](https://github.com/SignTools/ios-signer-ci) with the secrets you received before. The script will do the rest - fetch a signing job from the service, perform the signing, then upload the signed app. `trigger_body`, `headers` and `attempt_http2` are optional, you can use them to configure the communication with your builder, based on how you implemented the HTTP server. I hope I covered all points in the process. Please let me know how it goes and if you have any issues. The generic builder protocol is very new, and I haven't used it myself, so I am happy to amend it if you have any problems. My only concern is the fact that the script makes no attempt to clean up after itself, which is fine for CI builders as the environment is destroyed afterwards. As I said, I am happy to make improvements if that's an issue. Good luck!
Author
Owner

@ViRb3 commented on GitHub (Mar 14, 2021):

I am closing this now unless you have any other questions or issues.

<!-- gh-comment-id:798962242 --> @ViRb3 commented on GitHub (Mar 14, 2021): I am closing this now unless you have any other questions or issues.
Author
Owner

@ViRb3 commented on GitHub (Mar 17, 2021):

Hey @yacob841 I have created an official self-hosted builder server which is tightly integrated with this service. Read the new documentation to see how to set it up. Its repo is here: https://github.com/SignTools/ios-signer-builder

<!-- gh-comment-id:800727679 --> @ViRb3 commented on GitHub (Mar 17, 2021): Hey @yacob841 I have created an official self-hosted builder server which is tightly integrated with this service. Read the new documentation to see how to set it up. Its repo is here: https://github.com/SignTools/ios-signer-builder
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/SignTools#13
No description provided.