3 ms·

Every random piece of software expects some kind of file in the root directory of a project - this is not acceptable and leads to messy project layouts. Could

Every random piece of software expects some kind of file in the root directory of a project - this is not acceptable and leads to messy project layouts. Could developers of these tools please stop dictating where people have to put the "Blahfile" dsl config files and finally allow people to configure these kind of details. Also I would like to propose a common standard directory "projectroot/config" for these kind of files, NOT the project root directory itself. Thanks for your attention!

kbody 11y ago
"projectroot/config" it's too common and already used in different ways that will produce conflicts. If something is established it should be done in a proper way through a spec like semver was established.
- code_research 11y ago
  you could avoid conflicts by not naming your project files "Dockerfile" or "Jenkinsfile" or "travis.yml"...
  - mkobit 11y ago
    I don't like the Dockerfile or Jenkinsfile either, but I can kind of understand the .travis.yml. The good thing about the "Dockerfile" is that with most of the docker commands that interact with it, you can use the '-f' option to specify the file. For example "docker build -f dockerfiles/application.dockerfile" -t myapplication .". I don't see any easy way to do that with the Jenkinsfile. The amount of top-level files in these projects has started to become quite large, and it is unclear at first glance to see what it is important when exploring a new ecosystem. I'd like to see these products would move in a direction where these were would do any/some of the following: 1) use a file extension rather than "important" describing filename (.docker for Dockerfiles and .groovy/.jenkins for Jenkinsfile) 2) moved into a product specific folder (travisci/ci.yml, github/ for the issue and pull request templates) 3) use yet another top level file for indirection that is agreed upon (my initial thought is something named integrations.yml)
jacques_chester 11y ago
I've had this thought too, but I think the horses have well and truly bolted. Concourse lets you put the file anywhere; the act of applying configuration is distinct from committing it. Initially people put `pipeline.yml` or `concourse.yml` files in the top of their repo. It's rapidly evolved so that typically you'll find either `ci/pipelines/{some,number,of,pipelines}.yml` in the main repo, or a separate repo for the CI/CD system. I prefer the former, most teams I've seen so far prefer the latter.
empath75 11y ago
You don't need to call it Jenkinsfile. You can call it anything you want and put it anywhere you want.

kbody 11y ago

"projectroot/config" it's too common and already used in different ways that will produce conflicts. If something is established it should be done in a proper way through a spec like semver was established.

code_research 11y ago
you could avoid conflicts by not naming your project files "Dockerfile" or "Jenkinsfile" or "travis.yml"...
- mkobit 11y ago
  I don't like the Dockerfile or Jenkinsfile either, but I can kind of understand the .travis.yml. The good thing about the "Dockerfile" is that with most of the docker commands that interact with it, you can use the '-f' option to specify the file. For example "docker build -f dockerfiles/application.dockerfile" -t myapplication .". I don't see any easy way to do that with the Jenkinsfile. The amount of top-level files in these projects has started to become quite large, and it is unclear at first glance to see what it is important when exploring a new ecosystem. I'd like to see these products would move in a direction where these were would do any/some of the following: 1) use a file extension rather than "important" describing filename (.docker for Dockerfiles and .groovy/.jenkins for Jenkinsfile) 2) moved into a product specific folder (travisci/ci.yml, github/ for the issue and pull request templates) 3) use yet another top level file for indirection that is agreed upon (my initial thought is something named integrations.yml)

jacques_chester 11y ago

I've had this thought too, but I think the horses have well and truly bolted. Concourse lets you put the file anywhere; the act of applying configuration is distinct from committing it. Initially people put `pipeline.yml` or `concourse.yml` files in the top of their repo. It's rapidly evolved so that typically you'll find either `ci/pipelines/{some,number,of,pipelines}.yml` in the main repo, or a separate repo for the CI/CD system. I prefer the former, most teams I've seen so far prefer the latter.

empath75 11y ago

You don't need to call it Jenkinsfile. You can call it anything you want and put it anywhere you want.