Scheduled Pipelines Are Here

I’d like this at least to be an orb call with parameters.

I’ve started working on a CircleCI API orb wrapper for reusable requests like this, but it’s so far incomplete/unpublished and maybe not the recommended use/structure of orbs.

Hi @salil, Have the dates changed? According to the document did not see an exact date. All we see from the document is “Scheduled workflows will be phased out by the end of 2022.” Can we get an approximate date? Thank you.

1 Like

Hi @salil @thekatertot,

You have mentioned infra as code in your announcement.
We (Perception Point) need to specify the schedules via source control without managing them manually. This is a regulatory requirement.
It is a blocker for us to make the switch.
A terraform provider would be great!

Thank you in advance.

1 Like

Adding my feedback by way of support to those who have commented before me, specifically:

  • Scheduled pipelines should have feature parity with scheduled workflows before we are forced to convert.
  • Cron is a common, mature, concise, and robust scheduling syntax. I am unconvinced that your new custom scheduling syntax is better.
  • Infrastructure-as-code is a requirement for our project and many others, consistent with current DevOps best practices. Scheduled pipelines should be configurable in source control before we are forced to convert.
  • Your docs still say that scheduled workflows will be phased out by the end of 2022. Is December 31st the correct phase-out date, or is it another estimate, like June 3rd was?
  • We are paying customers. Please don’t force us to evaluate the cost of migrating to scheduled pipelines against the cost of migrating to one of your many competitors.
4 Likes

I have found another lack of feature parity: schedule workflows are not affected by auto-canceling older pipelines. Schedule pipelines do auto-cancel if enabled for the repository.

Hi,
I’d like to reiterate the concerns raised by others here by highlighting the importance for a GitOps compatible approach as a requirement.

Has there been any progress/news since this announcement was last updated in December '22, it would be useful to know requirements CircleCI intend to honour before scheduled workflows are deprecated again? I believe a good start would be to state CircleCI’s position on the concerns/issues raised throughout this discussion.

Thank you in advance.

3 Likes

If you follow this line of thought behind this change, then you’ll get rid of .circleci/config all together, and we will spend our lives doing click-ops.

GitHub Actions meanwhile continues to have excellent schedule support on workflows:

on:
  schedule:
    - cron:  '30 5,17 * * *'
2 Likes

Has anyone seen traction on this specific question? I cannot find anything in the ideas portal. I completely agree with @tetienne, particularly because Scheduled Workflows supports per-workflow schedules, but Scheduled Pipelines require me to add annotations every other workflow that should not be triggered by a schedule. That seems like unnecessary clutter in the CI config.

Nope. I’ve run far away from CircleCI. I know it’s not feasible for everyone, but they feel like a sinking ship.

2 Likes

Hi folks, I’m a product manager here at CircleCI. Thank you for the feedback and the patience on this item. As mentioned at the top of this thread, the deprecation of Scheduled Workflows continues to be postponed with no new timeline to share.

We are taking into consideration all feedback from this thread when determining next steps to improve the Scheduled Pipelines functionality before any deprecation plan is put in place and communicated.

1 Like

Moving from configuring something as code to an UI, while the whole industry is moving from UIs to configuring as code, is a strange move. It’s completely against the infrastructure as code mentality.

Circle CI argues in the introduction video, that it wants to allow other people to schedule this pipelines. What users do you have in mind, that don’t have access to the source code as well? It sounds like a very rare exception while for the majority of cases using the config file is the much much better option. So why did you made that decision?

I like the way GitHub Actions solves this with:

on:
  schedule:
    - cron:  '30 5,17 * * *'
1 Like