Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add schedule trigger to yaml #39

Closed
mikeharder opened this issue Oct 31, 2018 · 19 comments

Comments

@mikeharder
Copy link

commented Oct 31, 2018

Please add schedule triggers to yaml (currently not supported).

@dariustehrani

This comment has been minimized.

Copy link

commented Mar 20, 2019

I think this is an important feature in context of Infrastructure-as-Code and in particular Immutable Infrastructure builds.

Examples:

  • Building and maintaining OS Images with a pipeline e.g. using Packer:
    A Team might be maintaining various Packer Pipelines. (e.g. os-base-image, webserver-nginx, ubuntu-tomcat, etc.)
    Each time a new image is being introduced, they would want to utilize a template repository that contains both, packer definitions and azure-pipeline.yaml.

  • Building and maintaining Docker Images with a pipeline.
    Here a DevOps Teams might want to recurringly build these images against the latest OS Upgrades. If this cannot be scheduled recurringly, each time someone has to go in and hit unexpected surprises which can happen proactively when the pipeline runs scheduled.

Thanks,
Darius

@fcooper8472

This comment has been minimized.

Copy link

commented Apr 18, 2019

Another use case is testing stochastic (non-deterministic) functionality. I have a scenario where we would like to periodically run tests to build up many sets of outputs, from which we determine whether there are meaningful changes over time.

For example:

  • I have 20 different statistical optimisation algorithms
  • Every hour I want re-run the oldest test
@andyli

This comment has been minimized.

Copy link

commented Jun 19, 2019

Now my pipeline that has an existing scheduled trigger got the message as follows

You can no longer define scheduled triggers in the editor. Instead, you must add schedules to your YAML file. For more information, see https://go.microsoft.com/fwlink/?linkid=2080841

But there is no info on how to add schedules to yaml in the mentioned link.

@thedustinsmith

This comment has been minimized.

Copy link

commented Jun 19, 2019

I'm having the same problem @andyli is having. It's worth mentioning that there's more documentation for yaml triggers here: https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#scheduled-triggers.

However ...

Scheduled builds are not yet supported in YAML syntax. After you create your YAML build pipeline, you can use pipeline settings to specify a scheduled trigger.

UPDATE
Just found this feedback thread: https://developercommunity.visualstudio.com/content/problem/607414/scheduled-trigger-for-yaml-pipeline-disabled.html

This format worked for me:

schedules:
- cron: '0 18 * * *'
  displayName: Every night at 6pm
  branches:
    include:
    - master
@vtbassmatt

This comment has been minimized.

Copy link
Member

commented Jun 20, 2019

@steved0x @vijayma can you get the official docs up and the FWlink updated to point to it? Thanks.

@elenst

This comment has been minimized.

Copy link

commented Jun 25, 2019

The manual now has some mention of the schedule configuration, but it is far from sufficient for transferring scheduled triggers to YAML. Let's say I have two pipelines A and B which use the same YAML file x.yml, but with different variables and variable groups and different schedules, e.g. pipeline A is configured with a variable group DEBUG_BUILD and a variable TEST=quick and runs once a day, and pipeline B is configured with a variable group RELEASE_BUILD and a variable TEST=full and runs once a week. The manual doesn't say anything about variables or variable groups in the YAML schedule configuration, and from the current look of it, this configuration cannot be transferred to YAML at all. I hope it's a documentation oversight, because duplicating YAML files isn't a really a viable option for real-life setups which can have dozens of such parallel configurations.

@vtbassmatt

This comment has been minimized.

Copy link
Member

commented Jun 26, 2019

Having different schedules for different pipelines but using the same YAML is not supported. You can factor out your pipeline logic into a template, and then have a very small YAML wrapper that just includes the schedule triggers and imports the template.

@vtbassmatt

This comment has been minimized.

Copy link
Member

commented Jun 26, 2019

(And we will definitely consider this feedback as we evolve the feature - thank you!)

@elenst

This comment has been minimized.

Copy link

commented Jun 26, 2019

So, just to make sure I understand -- it was fully supported in UI, then scheduling got removed from UI with the suggestion that it should be done in YAML instead, but there is no way to do it in YAML. Is it correct? Or do you mean that it was an unsupported feature in the UI as well, it just happened to work?
And yes, I fully understand that I could do it as you said, but the reality is (and I suppose not just mine), that I have over 40 pipelines using the same YAML with different options and running on different schedules, so I will need over 40 wrappers, which is hardly maintainable.

@vtbassmatt

This comment has been minimized.

Copy link
Member

commented Jun 26, 2019

Our view of config-as-code is to push as much configuration into the code file as possible, rather than have some in code and some in a database. Is maintaining 40 YAML files more effort than maintaining 40 point-and-click schedules? (That's a genuine question - there may be something here I'm not considering.)

@elenst

This comment has been minimized.

Copy link

commented Jun 26, 2019

Numerous YAML files pollute the source tree, and frequent updates to them flood git history; but it's a rather small (and maybe arguable) nuisance.

The problem is, config-as-code approach in its current form doesn't replace the UI configuration. If I were now able to have only one UI pipeline which would magically run with different YAML files and different parameters on different schedules, it would be all right, but it's not so, I still have to have the same 40 UI pipelines, but now also 40 YAML files instead of only one, and keep them in sync. Whenever I need to add or remove a configuration, I will need to do it in two places, as a YAML with the schedule and as a UI pipeline. Changes in schedule also usually come together with configuration changes (you modify certain parameters and because of that, change the schedule to make the run more or less frequent), so again, two places instead of one.

Anyway, I appreciate the clarification, I needed to make sure I'm not missing anything, because converting the scheduled setup from UI to YAML is a big job which I didn't want to do just out of ignorance.

@juanperezADD

This comment has been minimized.

Copy link

commented Jun 27, 2019

As per the docs, scheduled triggers are not yet supported in YAML syntax with Azure DevOps Server.

Is there any plan to support it?

@vtbassmatt

This comment has been minimized.

Copy link
Member

commented Jun 27, 2019

It should be available in a future Azure DevOps Server release. (I don't believe it made the cutoff for 2019.1, though.)

@vtbassmatt

This comment has been minimized.

Copy link
Member

commented Jun 27, 2019

Since this feature has shipped, closing the issue.

@vtbassmatt vtbassmatt closed this Jun 27, 2019

@vutkin

This comment has been minimized.

Copy link

commented Jul 16, 2019

Hello all, I am unable to delete current schedule from UI, what is wrong with you dev team?

Besides if I need to create multiple pipelines from single yaml file now they will have same schedule? Really?

Why I can't override schedule from UI as for trigger?

@vijayma

This comment has been minimized.

Copy link

commented Jul 16, 2019

We are working on enabling the UI again for the schedules. You will be able to use YAML for the scheduled, but if you do not want to, you can continue to use the UI. Sorry about the trouble.

@buckleyGI

This comment has been minimized.

Copy link

commented Jul 18, 2019

Hello Vijayma,

Our build was using the GUI schedule even though it isn't supported anymore.
So my plan was to add the schedule to the yaml and delete the GUI schedule.

However I am not able to delete the schedule even though there is a trash icon present. Clicking on it does not nothing.

To give some feedback I am all for putting config in code and under source control (everything should be) so I am all for this move.

For feature parity though (GUI<->Yaml) I think releasing the feature it without timezone support is premature. We now have cadence of our master build of 3h,12h,20h and it's summer here. When it is winter this suddenly becomes 2,11,19 and we have to manually adjust and other dependent process will fail because of this change. Yes, we observer daylight saving time in the EU for at least a year more :)

@vijayma

This comment has been minimized.

Copy link

commented Jul 18, 2019

I understand. Thanks for the feedback on timezone support.

@nickforr

This comment has been minimized.

Copy link

commented Jul 24, 2019

Having different schedules for different pipelines but using the same YAML is not supported. You can factor out your pipeline logic into a template, and then have a very small YAML wrapper that just includes the schedule triggers and imports the template.

Being able to refer to a 'Schedule.Reference' (for example) would be extremely useful for then only running certain steps (as per @elenst post).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.