Is there any documentation on how to authenticate and run a build via a REST api? We need manual input to run some of our pipelines/jobs and wanted to have a user fill out a form then run the build.
couldn’t you just use the fly cli in your api?
In case you want prefer the API take a look at the verbose flag of fly.
--verbose Print API requests and responses
That could work, but I don’t see how you can pass parameters into a job. say you have a deploy pipeline and want to pass in the version it should deploy… I know you can set vars for a pipeline but we have vars that need to change per job execution i.e the version.
From what I see, the only way to do that is set the vars on the pipeline then run the job?
Maybe you can solve the problem on another end. Instead of passing a version into the pipeline using a variable and then call
fly sp, you should think if you can solve the problem with a resource e.g. git resource or s3 resource.
E.g. use a s3 verfioned_file in your bucket that is called
deployment_version you just have the desired string that describes the version the pipeline shall deploy.
Define your s3 resource using the
versioned_file source parameter and set the trigger to true -> every time you update your
deployment_version file, your pipeline will be triggered with the apropriate version.
The same thing could be done with Github & git resource as well.
My coworker rolled out something for this the other day that’s pretty slick. User input goes into a queue, and there’s a resource to pull things off of the queue. The
get step is marked with
version: every so it doesn’t skip items in the middle.
can you describe a bit more in detail how this works?
Would also be interesting to understand your approach for us.
Sure- we have a custom Concourse resource around a standard bit of queuing software. The frontend puts a JSON blob in the queue with all of the various options.
check binary outputs every item currently in the list, and the
in script removes the item from the queue and writes it to a file.
The work is done by a Concourse task that reads the JSON configuration blob supplied by the resource.
version: every thing is because by default, Concourse processes just the last version supplied by the
check. This is great for testing software, you don’t do a bunch of extra unnecessary work, but for this we want to do everything.
This works better with something that’s not a pure queue, like redis PUSH/POP, but something where the items have unique IDs- Concourse wants to dispatch each
in with a unique ID to run with.
nice, this can be useful. Thanks!