Imported config results in out of order build stage

Early Releases
, ,
1

We use imported configs to import a deploy job configuration, but have the test configuration specified directly in the travis.yml. As of 6 days ago (April 22) our imported configs resulted in test job build stage running before the deploy stage as expected. As of 5 days ago, that appears to have changed, so now we end up running our deploy stage prior to our test stage, which isn’t desirable. Is this expected?

2

Worth noting that I noticed our “Build Config” jobs attribute now looks like this:

"jobs": {
    "include": [
      {
        "stage": "deploy",
        "name": "Publish with semantic-release",
        "script": [
          "skip"
        ],
        "deploy": [
          {
            "provider": "script",
            "edge": true,
            "script": "npx semantic-release",
            "on": {
              "all_branches": true
            }
          }
        ]
      },
      {
        "stage": "test",
        "if": "branch != alpha"
      }
    ]
  }

whereas as of 6 days ago that was switched so that test was first.

3

Please link to a build, otherwise there’s not enough information.

In particular, did you specify stage order?

Without it, the documentation doesn’t specify which order the stages would be in.

4

Sorry this is a private repo so can’t link to it. I haven’t seen one come up yet in my public repos, but if that happens I sure can. I am not currently specifying the stage order. You make a good point that it is not defined what default order jobs will take. In my head the standard job-lifecycle stages would get run in the standard job lifecycle order, but to your point that is not stated in the docs in regard to importing configs. I will go ahead and pin the order, but it’s worth considering that this can be somewhat misleading. Specifically the confusion between job “stages” and build “phases”.

5

I was able to specify the stages to control order. I think my core confusion came from the fact that job stages don’t conform to the the phase ordering, even though they generally use the same name convention like deploy in the docs.

6

Good point, but stage names are not standardized (except the default stage, “test”). So Travis cannot know how you will call your “deploy” stage. E.g. in one of Travis’ own repos, it’s called “:ship: it to Quay.io” (yes, with an emoji).

On the contrary, it’s very good that Travis uses different terms for these two similar but distinct things.

Especially since phases are parts of a job and stages – of a build :slight_smile:

7

:+1: Appreciate the pointer in the right direction!

8

While the docs don’t explicitly specify a default order, this quote from here pretty strongly suggests that test defaults to first:

This is mostly useful in order to “prepend” a stage to the test stage that jobs resulting from the matrix expansion will be assigned to.

I’ve always understood that to mean that an order doesn’t need to be explicitly specified unless there is a need to adjust from the default order (where test is first).

in addition, my experience is similar to @richardson-trevor where test has always defaulted to first in the past. i have not personally seen this problem yet, but it is a surprise to me since i do not specify order either and have not had issues like this previously.

1 Like
9

Yes, I saw that, and am pretty sure that was the initial intention. But since they didn’t state that explicitly, they likely didn’t make a test for that, and now that they’ve started to juggle with stage names, we have what we have.

10

Actually, you can, but only Travis staff members will be able to open that link.

11

If someone from Travis chimes in here and finds this to be incorrect behavior I’d be happy to shoot them a message with the build link.

12

Hello,

I have a similar issue since 5 days.

For exemple this is my .travis.yml

import:
  - source: ***/travis:common.yml@master
    mode: deep_merge_append

env:
  global:
    - deploy_qual=true;
    - config_file_public="src/js/config.json"
    - config_file_private="src/private/js/config.json"

My common.yml :

env:
  global:
    - blop=blip;

Normaly if you look that the result of merge should be :

env:
  global:
    - deploy_qual=true;
    - config_file_public="src/js/config.json"
    - config_file_private="src/private/js/config.json"
    - blop=blip;

but since the bug the result on config view are :

    - blop=blip;
    - deploy_qual=true;
    - config_file_public="src/js/config.json"
    - config_file_private="src/private/js/config.json"

Look like an inversion of merge mode because for an other project deep_merge_prepend was used and we have the inversed issue.

13

I fount this suspicious commit but i don’t know ruby language. https://github.com/travis-ci/travis-yml/commit/6a8d3c27976117b81e02c155a3ff9be6a56fa7bf

14

Here is repository with multiple imports, each doing ‘echo “Number Source”’
Numbers expected to go 1-2-3-4…-8 as they used to be printed
Now the order is broken

Links:
Repo - https://github.com/vend/travis-imports-issue
Build - https://travis-ci.com/github/vend/travis-imports-issue

1 Like
15

A post was split to a new topic: Imported config results in out of order build stages despite order explicitly specified