+------------------------------------------------------------------------------+
| (3) build-router-start@0.11.2 |
+------------------------------------------------------------------------------+
| id: build-router-start |
| version: 0.11.2 |
| collection: https://github.com/bitrise-io/bitrise-steplib.git |
| toolkit: go |
| time: 2019-04-19T13:55:04Z |
+------------------------------------------------------------------------------+
| |
Config:
- AppSlug: [REDACTED]
- BuildSlug: ***********
- BuildNumber: 6
- AccessToken: *****
- WaitForBuilds: false
- Workflows: ios
android
- Environments:
Starting builds:
Failed to start build, error: failed to get response, statuscode: 400, body: {"status":"error","message":"workflow (ios) did not match any workflows defined in app config","slug":"[REDACTED]","service":"bitrise"}
| |
+---+---------------------------------------------------------------+----------+
| x | build-router-start@0.11.2 (exit code: 1) | 4.13 sec |
+---+---------------------------------------------------------------+----------+
| Issue tracker: ...com/bitrise-steplib/bitrise-step-build-router-start/issues |
| Source: https://github.com/bitrise-steplib/bitrise-step-build-router-start |
+---+---------------------------------------------------------------+----------+
Is this even possible to use this approach when my configs are hosted in git? It appears to fail to trigger a workflow which is only available through git.
Currently in this implementation the build-router-start step would expect the ios and android workflows to be present in the bitrise.yml that is stored online as well. When starting a build with this step it triggers a build on our website and the previously mentioned workflows are only available in the bitrise.yml stored in your repo.
What can be a possible solution for your case would be to create workflows with the same name on our website as well and these workflows would contain the steps needed for cloning the repo and a Bitrise Run step to start the workflow with the same name from the specified bitrise.yml in your repo. So basically a workflow that is stored in our yml on our website would look something like this:
thanks @tamasbazsonyi, however this is kind of a solution I wanted to avoid since I would really prefer to keep config in the repo as a single source of truth
as an alternative I’m considering sending workflow id as an env variable, do you think this might work?
@max That would be perfectly doable as well, but the implementation would be pretty similar in that case I’d say you’d need a default runner workflow. So basically what you would be doing is triggering a common build which would get the workflow to build as an env var. In this case you’d also need different build-router-start steps if you want to trigger multiple workflows and these steps would look something like this:
The WORKFLOW_TO_RUN env var would indicate which workflow should be ran from the yml in the repository and the runner_workflow. Let me know if you’d have any issues or questions Also if you’d need a sample for these workflows let me know and I’ll be more than happy to put together a sample for you