How to Limit what can trigger a build on Cirrus CI

[confused-Techie]

With the bigger changes going on over here at Cirrus, I'm hoping to limit the amount of builds that are run for one of my repositories, but reading through the docs I'm having a hard time finding out how to do what I'm hoping.

I'm hoping to limit Cirrus builds like so:

• Cron: We have a cron job set to run roughly every two days, which works beautifully.
• Manual: Let a build be triggered manually
• Required PR Label: A specific PR label that can run the task

Thing is, I'm hoping to enforce these as the only way to trigger a Cirrus build.

If I add both:

required_pr_labels: initial-review
trigger_type: manual

Will this work? Or will the trigger_type field disallow those being started by a PR? And if trigger_type is set to manual does that mean the cron jobs will also be disallowed?

Is there anything I can inspect within the cirrus script to conditionally start a task based on what triggered it? Similar to the GitHub Actions github.events context?

As you can see I'm a little stuck, but I'm hoping there's a way to restrict builds only to the three events listed above, or at least a subset of them, or at the very least a way to disable automatic tasks on every commit and PR, would greatly appreciate any assistance. Thanks!

---

EDIT:

Would it be possible to add an only_if where I check if CIRRUS_CHANGE_MESSAGE is a string? So that potentially I can disable runs for both any commit and PR? I know this goes against one of my listed wants above, but at the very least would restrict builds to only Cron jobs, and manual jobs. Then instead of a PR suppose I could just use the creation of a tag as the trigger, so it would work.

Since to put those requirements into real world usage:

• Build a 'rolling' release every other day
• Build a 'regular' release when we do a full release attached to a tag and GitHub release

[DeeDeeG]

Hi, I'm another member of the same team (pulsar-edit org on GitHub). So, I totally concur with this post, we want to know how to block most types of builds to control credit use.

EDIT: I realize the crux of my original comment was a tangentially related feature request, kind of off-topic or more of a long-term thing, whereas original post is a short-term question, so I'm hiding it behind an expandable thingy...

Original comment (click to expand):

My two cents: I hope [eventually] these restrictions can be done on the Cirrus site's settings dashboard, so various GitHub users have no way to evade the restrictions (or simply edit them out of .cirrus.yml).

(The permissions model being a privileged team member-only action, not editable in a regular config file in the repo (for example in a drive-by PR) is what I'm thinking of.)

The motivation to restrict what can trigger builds is to preserve the credits, as we are being very careful to budget our use within the free credit allocation.

More about the motivation (click to expand, if you want):

Not being able to effectively limit builds makes the credits (especially the first 50 free credits) feel a little unpredictable to use and make plans around. (In an example: We could go from $0 to suddenly tens or hundreds of dollars. And someone might be able to deliberately target and use up our credits if we can't lock it down. So, that is a very different scenario for planning and budgeting.) Even if we are willing to pay some amount to cover our usage, not being able to confidently specify what the usage goes toward sort of reduces the value proposition of what we can consider the credits are good for. We have to have a way to be very deliberate about what we spend money for, since we are crowd-funded and we are stewarding donated money for our operations. We have the public trust to keep in mind as for how we spend these credits/CI costs. So we want to be sure they are accomplishing something useful for the project only.)

---

[ EDIT to clarify: We are of course also hoping to lock down what triggers our builds within the next few days, with existing technologies. I realize my comment reads like a feature request. For the medium-to-long term, I do hope for a way to do it in the Cirrus settings dashboard. But I suppose @confused-Techie was just asking how we can even restrict these things today, with .cirrus.yml and that kind of approach. Before free credit usage becomes limited. ]

[fkorotkov]

Hey @confused-Techie,

If we are talking only about the two use case from the edit (rolling on a cron invocation and release on a Github Release), then you can utilize CIRRUS_CRON environment variable which will contain name of the cron configuration (e.g. daily) and CIRRUS_TAG environment variable that will contain tag name. You can check this example of a configuration where we have a two tasks: one updates virtual machines monthly and the other builds the latest one on a GitHub release.

As for the initial question:

• Cron builds are configurable in the repository settings.
• Manual builds can be achieved either by trigger_type: manual or better yet via the required_pr_labels: initial-review. Don't think you actually want both.

Finally, you can program Cirrus configuration with Starlark which can give you even more flexibility. Here is an example how you can construct tasks from multiple sources:

# .cirrus.star
load("cirrus", "env", "fs")

def main(ctx):
  if env.get("CIRRUS_TAG") != None:
    return fs.read(".cirrus.release.yml")
  if env.get("CIRRUS_PR") != None:
    return fs.read(".cirrus.pr.yml")

  return fs.read(".cirrus.pr.yml") + fs.read(".cirrus.e2e.yml")

[confused-Techie]

Thanks a ton for taking the time to help out here.

Does seem like using Starlark will be the best way to achieve what I'm wanting to accomplish. I'll try that out and fingers crossed works how we are hoping, appreciate it