# Imported config results in out of order build stage
**URL:** https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381
**Category:** Early Releases
**Tags:** bug, build-stages, config-import
**Created:** [April 28, 2020, 3:43pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381 "2020-04-28T15:43:46Z")
**Posts on this page:** 15
**Page:** 1
### Author:  [@richardson-trevor](https://travis-ci.community/u/richardson-trevor)
#### Post date: [April 28, 2020, 3:43pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/1 "2020-04-28T15:43:46Z")
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?
---
### Author:  [@richardson-trevor](https://travis-ci.community/u/richardson-trevor)
#### Post date: [April 28, 2020, 3:48pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/2 "2020-04-28T15:48:24Z")
Worth noting that I noticed our “Build Config” `jobs` attribute now looks like this:
```auto
"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.
---
### Author:  [@native-api](https://travis-ci.community/u/native-api)
#### Post date: [April 28, 2020, 6:06pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/3 "2020-04-28T18:06:16Z")
Please link to a build, otherwise there’s not enough information.
In particular, did you [specify stage order](https://docs.travis-ci.com/user/build-stages/#specifying-stage-order-and-conditions)?
Without it, the documentation doesn’t specify which order the stages would be in.
---
### Author:  [@richardson-trevor](https://travis-ci.community/u/richardson-trevor)
#### Post date: [April 28, 2020, 6:16pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/4 "2020-04-28T18:16:32Z")
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](https://docs.travis-ci.com/user/for-beginners/#builds-jobs-stages-and-phases), 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”.
---
### Author:  [@richardson-trevor](https://travis-ci.community/u/richardson-trevor)
#### Post date: [April 28, 2020, 6:31pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/5 "2020-04-28T18:31:31Z")
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.
---
### Author:  [@native-api](https://travis-ci.community/u/native-api)
#### Post date: [April 28, 2020, 6:34pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/6 "2020-04-28T18:34:23Z")
> [@richardson-trevor](#):
>
> In my head the standard job-lifecycle stages would get run in the [standard job lifecycle order](https://docs.travis-ci.com/user/for-beginners/#builds-jobs-stages-and-phases)
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](https://travis-ci.org/travis-ci/travis-build/builds/552914301), it’s called _“🚢 it to [Quay.io](http://Quay.io)”_ (yes, with an emoji).
> [@richardson-trevor](#):
>
> Specifically the confusion between job “stages” and build “phases”.
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 🙂
---
### Author:  [@richardson-trevor](https://travis-ci.community/u/richardson-trevor)
#### Post date: [April 28, 2020, 6:36pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/7 "2020-04-28T18:36:16Z")
👍 Appreciate the pointer in the right direction!
---
### Author:  [@travi](https://travis-ci.community/u/travi)
#### Post date: [April 28, 2020, 7:24pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/8 "2020-04-28T19:24:17Z")
While the docs don’t explicitly specify a default order, this quote from [here](https://docs.travis-ci.com/user/build-stages/#specifying-stage-order-and-conditions) 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.
---
### Author:  [@native-api](https://travis-ci.community/u/native-api)
#### Post date: [April 28, 2020, 8:01pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/9 "2020-04-28T20:01:01Z")
> [@travi](#):
>
> this quote from [here](https://docs.travis-ci.com/user/build-stages/#specifying-stage-order-and-conditions) pretty strongly suggests that `test` defaults to first:
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](https://travis-ci.community/t/travis-build-stage-name-isnt-capitalized/8220), we have what we have.
---
### Author:  [@native-api](https://travis-ci.community/u/native-api)
#### Post date: [April 28, 2020, 8:06pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/10 "2020-04-28T20:06:26Z")
> [@richardson-trevor](#):
>
> Sorry this is a private repo so can’t link to it.
Actually, you can, but only Travis staff members will be able to open that link.
---
### Author:  [@richardson-trevor](https://travis-ci.community/u/richardson-trevor)
#### Post date: [April 28, 2020, 8:11pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/11 "2020-04-28T20:11:36Z")
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.
---
### Author:  [@acacopardo](https://travis-ci.community/u/acacopardo)
#### Post date: [April 29, 2020, 1:22pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/12 "2020-04-29T13:22:48Z")
Hello,
I have a similar issue since 5 days.
For exemple this is my .travis.yml
```auto
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 :
```auto
env:
global:
- blop=blip;
```
Normaly if you look that the result of merge should be :
```auto
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 :
```auto
- 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.
---
### Author:  [@acacopardo](https://travis-ci.community/u/acacopardo)
#### Post date: [April 29, 2020, 2:08pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/13 "2020-04-29T14:08:11Z")
I fount this suspicious commit but i don’t know ruby language. [https://github.com/travis-ci/travis-yml/commit/6a8d3c27976117b81e02c155a3ff9be6a56fa7bf](https://github.com/travis-ci/travis-yml/commit/6a8d3c27976117b81e02c155a3ff9be6a56fa7bf)
---
### Author:  [@tenitski](https://travis-ci.community/u/tenitski)
#### Post date: [May 13, 2020, 3:10am UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/14 "2020-05-13T03:10:35Z")
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](https://github.com/vend/travis-imports-issue)
Build - [https://travis-ci.com/github/vend/travis-imports-issue](https://travis-ci.com/github/vend/travis-imports-issue)
---
### Author:  [@native-api](https://travis-ci.community/u/native-api)
#### Post date: [July 8, 2020, 11:28pm UTC](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stage/8381/15 "2020-07-08T23:28:44Z")
A post was split to a new topic: [Imported config results in out of order build stages despite order explicitly specified](https://travis-ci.community/t/imported-config-results-in-out-of-order-build-stages-despite-order-explicitly-specified/9290)