CircleCI Ideas

Sort jobs in workflows UI

We don't display jobs in the order they're defined in config.yml, nor do we sort those jobs in alphabetical order.  Jobs are defined in config.yml using an ordered list, so this ordering should be preserved.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Sep 5 2017
  • Taking votes
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    September 07, 2018 21:32

    please consider this feature, its confusing seing some expected ordered jobs, to be in a random order every time I do a refresh in the page

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    13 Feb 01:59

    Facing the same issue. This has been in the backlog for many months. Please help resolve it.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    31 May 18:26

    This is our single largest pain point as a new adopter with a complicated workflow.

  • Admin
    Kate Catlin commented
    07 Jun 16:33

    Hi all,

    This is something we're currently debating. Right now, the jobs are ordered chronologically as they run. That can be helpful to some in debugging because occasionally there's an unforeseen dependency problem and a build fail is rooted in whether one job is running prior to another. However, I also see and understand the merit of a predictable order of jobs on your workflow map as well.

    I'd like to understand the process and mindset you're coming from in proposing this idea better. Would any of you be interested in doing a formal user-interview with us? This is a 1-hour recorded video call in which we'll preview our new UI designs to you and assess whether we've solved your problems. We're happy to share a $50 gift card as a token of our gratitude if you participate.

    If you're open to it, please book some time here: https://calendly.com/circleci-xteam/60min

    Thank you in advance, hope to learn from some of you.

    Kate Catlin

    Product Manager, Developer Experience

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    27 Jun 21:02

    Just noticed this as well.  The lines get all criss-crossed no matter what order you put the jobs in the YAML file.  It would be nice if each parallel series of stuff stayed in its own "lane" so to speak.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    07 Aug 19:08

    Dear Kate,

     

    I understand where your concern comes from, but I think the current situation neither satisfies your desire nor those who want a "nicer view".  The order is not the "execution order" of the jobs, or at least it usually is a pretty random order , and then they are executed in a pretty random order (in our workflows at least).  But, even if it was the execution order, that only holds within the same "column" or "depth".  So if my jobs would have side effects that influence other jobs, I wouldn't see that order among jobs which are on different levels.

     

    This seems to be a purely UI issue. My humble suggestion would be to have two views on the ui:

     1. dependencies not shown, simple list of jobs, as they are being / were executed

     2. the current graph with keeping the order as defined in the config file if on the same level

     

    The 2nd could be made a little bit nicer with some vertical shifts, so that the lines do not cross each other unnecessarily, But even the simplest solution would be a huge help imho. 

     

    I am a bit annoyed with the current solution because of :

     - criss-cross deps, that are untraceable 

     - even if we have the same workflow, and I'm looking for a job, I always have to go through the whole list, and find the one I'm looking for. 

     

    The latter can be especially annoying if the job names try to be explanatory and long, or we use parametric jobs without the name parameter. 

     

    In my current scenario I'm experimenting with approval type jobs. Simple workflow, where I have 3 independent options (E.g. deploy to S1, S2, S3, etc.) I have a job for approval, and then a job that really does the thing.  This should look like: 

     

    Deploy to S1?  -------------- Deploy to S1

     

    Deploy to S2?  -------------- Deploy to S2

     

    Deploy to S3?  -------------- Deploy to S3

     

    Instead, it looks like this:

     

    Deploy to S3?  ------+------- Deploy to S1

                                                |

    Deploy to S1?  ------+------ Deploy to S2

                                                |

    Deploy to S2?  ------+------ Deploy to S3