Sometimes you need a really dynamic configuration when setting up your pipeline. With imported configs, those configs can themselves include other configs, making this feature very composable (cyclic imports will be skipped). Let\u2019s get started.<\/p>\n\n\n\n
When using Build Imports, remember that the main source of configuration for your build is the Now, let\u2019s make a folder called in your project called\u00a0 You\u2019ll see the second imported configuration entitled\u00a0 So you can see above, there\u2019s one master You\u2019ve just used Build Imports in Travis like a pro! As per usual here\u2019s an example repo<\/a> I\u2019ve made so you can follow it step by step and start using Build Imports.<\/p>\n\n\n\n.travis.yml<\/code> file stored in the root directory of your project. So for example, here\u2019s my root .travis.yml<\/code>:<\/p>\n\n\n\nlanguage: ruby\n\nscript: echo \"It's Friday, which means blog day by Montana Mendy!\"\n\nimport:\n - .\/.travis\/all-the-rubies.yml\n - .\/.travis\/only-some-branches.yml<\/code><\/pre>\n\n\n\n.travis<\/code>, and in there, we\u2019ll have a file called\u00a0all-the-rubies.yml<\/code>, here\u2019s the content of this configuration:<\/p>\n\n\n\nrvm:\n - 2.2\n - 2.3<\/code><\/pre>\n\n\n\nonly-some-branches.yml<\/code>\u00a0in the\u00a0.travis<\/code>\u00a0folder in our project. Now here\u2019s the content of that configuration file I made:<\/p>\n\n\n\nbranches:\n only:\n - master\n - develop<\/code><\/pre>\n\n\n\n.yml<\/code> config, and you can think of the other two configurations as child<\/code> configurations. You can imagine with our Build Matrix feature and using Build Imports how flexible your builds can really be.<\/p>\n\n\n\nConclusion<\/h2>\n\n\n\n