[Product Update] Simplifying CircleCI Project Creation

[sebastian-lerner]

CircleCI is testing a new experience that aims to help you bootstrap the project creation process. For new projects created by new users:

1. If a .circleci/config.yml already exists in the repository, CircleCI will use that config.yml to trigger pipelines
2. Else: CircleCI auto-generate a config.yml with build & test jobs that are applicable to your application

CircleCI will try and detect the following languages/frameworks to generate the build & test jobs:

1. Javascript / Typescript / jest
2. Python / pytest
3. Go / gotestsum
4. Ruby / rspec
5. Java
6. Rust
7. PHP

If CircleCI cannot detect and generate a build or test job, CircleCI will generate a fallback template with a stubbed build, test, and deploy workflow that you can use to build your own configuration file (config.yml).

To view the auto-generated config.yml, navigate to the “in-app config editor” by clicking on “Configuration File”.

If CircleCI was able to auto-generate a build and test job from your language/framework, you’ll see the commands that we used to run tests and build artifacts.

If you are seeing a “fallback template” , each job definition has a place to replace a command with your specific build, test, or deploy commands:

To make changes to this file, copy the contents, edit it in your IDE or text editor of choice, and commit the modified file to your default branch in a new .circleci directory with the name config.yml.

Once it’s committed as .circleci/config.yml in your default branch, it will be used as the source for running pipelines on subsequent commits.

You can see the open source library used for config.yml generation here. Questions or feedback? Respond to this thread or email me at sebastian @ circleci.com

[rit1010]

Can you provide a system-wide setting to turn the auto script build feature off?

Why you may ask, well

• Firstly you are creating a script that when run will incur an operational cost, even if it is just for a few seconds you are going to be billing the end client for the resources used.

• You could find that for a very small number of users the resulting cost could become something of an issue. Your example script includes checkout steps - you have no way of knowing if the checkout of the whole of the repo makes any sense. For all you know, you could be starting the checkout of a large monorepo, which could have major time and i/o costs.

• I think you will many people with responsibility for a company’s repo expect changes to take place to those repos by the direct actions of staff members, rather than third parties.

Being able to disable this feature system-wide is a far better option than having to make sure that every repo branch across a team/company that could cause an issue has a default config.yml.

[sebastian-lerner]

Thanks @rit1010 for the feedback, answered a similar question here: New "Set Up Project" functionality is worse than previous functionality, looking for work-arounds - #3 by sebastian-lerner

If we make updates to the behavior, I will update this post as well.