Trigger workflow by API


#1

I know this is similar to Trigger workflow through REST API, Workflow job trigger from api, Workflows triggers and branches and How to trigger manual workflow runs?, but those are all locked. I used the API in 1.0 to trigger nightly builds; the nightlies did more tests so I only want to run those once a day instead of at every build. But with 2.0 I can only trigger individual jobs, not a workflow, so my build-test workflow cannot be triggered. Any updates on when a workflow-capable endpoint will be available? I’d rather not have to resort to polluting my git history with empty commits just to trigger the nightlies.


#2

I’m just thinking aloud here. If a commit would kick this off, can you emulate that signal coming from your repo provider? I am wondering if GitHub/BitBucket/etc make an HTTP request when a push event happens, and I wonder if that can be replicated without a new commit?


#3

Is a “nightly” every night? If so, can you just use a workflow schedule instead? That’s supported out-of-the-box in Circle.


#4

I can’t fake a github commit as they share a secret I don’t have, but a worfkflow schedule sounds just like what I need. So:

  1. I found this, but I’m not sure how I have one workflow triggered by a commit only, and the other on a schedule only.
  2. Can the scheduled workflow detect it’s being scheduled? I want to run the regular build but detect from ENV vars that I’m running the nightly.

#5

For your first question, see my config here.

For your second question, that’s an interesting one - I don’t know. Have a look at the env vars available to see if anything is different between a commit and a schedule.

You could also try doing something clever with the cache system - if the commit hash at build is the same as the previous one, then you know that the build was not triggered on a commit.


#6

So is the name “commit-workflow” special, or does the lack of triggers mean “trigger on commit”?

If I echo my environment, will CircleCI block out the contents of my project vars? There’s API keys in my project env vars. I’d rather not diddle with the commit hashes – there’s other jobs I may want to schedule and looking at the hash would be fragile.


#7

The spin-up step already echos my env vars, and while the build step is there, the workflow name isn’t.


#8

It looks like I could use contexts, but I don’t see “Settings > Contexts” in my project (I can see the Settings, but no Contexts).


#9

NM, found the contexts, we’ll see what happens tonight!

Still curious to know whether the name “commit-workflow” special, or does the lack of triggers mean “trigger on commit”.


#10

You’re welcome.

The latter. I think I made up the name.


#11

Looks like I have everything in place then. Super thanks!

Any idea what timezone Circle lives in? I’ve set my nightly at midnight but I’ve just realized that’s most likely not my midnight.


#12

For the curious, my config is here.


#13

Great work :smile:

The server locations are noted here, though you can get TZ information by getting a post-build SSH session.

My default TZ on my local machine is “GMT”:

$ date
Wed 21 Mar 00:23:19 GMT 2018

What another TZ looks like (“PDT”):

$ TZ='America/Los_Angeles' date
Tue 20 Mar 17:23:15 PDT 2018

#14

It ran at 01:00 my time (which is fine), it ran! and it caught a thing too. Super happy!


#15

You can set environment variables for any job. So you can do that in the one configured for a Scheduled Workflow and then look for that variable.

The build machines themselves can vary at times due to the way infrastructure scales, but with Scheduled Workflows the times are always in UTC.


#16

Hi, I know I can set any variables in the job specification, but I don’t want a specific job to run at midnight, I want the regular “on-commit” workflow to run at midnight, with one extra variable to detect the job was the nightly build. The build behaves exactly the same, it just adds a few test cases that take more time to run. I’d have to duplicate the test job specification in the config.yml just to set an extra var just so I could detect it’s the nightly run.

I’ve been able to do it using contexts, but under 1.0 I could trigger a build (which could fan out and in) using the api, and when triggering I could pass any env var I wanted. I used IFTTT to trigger it and that worked well. But under 2.0, if you want fan out - fan in, you must use workflows, and workflows can’t be triggered using the api, just individual job steps.


#17

Thanks for the feedback. I can see that’s more work to duplicated the job specification.

We are working on full API access for Workflows. I don’t have an ETA right now, but it’s a high priority for us.


#18