{"action":"created","issue":{"url":"https://api.github.com/repos/gocd/gocd/issues/1133","labels_url":"https://api.github.com/repos/gocd/gocd/issues/1133/labels{/name}","comments_url":"https://api.github.com/repos/gocd/gocd/issues/1133/comments","events_url":"https://api.github.com/repos/gocd/gocd/issues/1133/events","html_url":"https://github.com/gocd/gocd/issues/1133","id":77045258,"number":1133,"title":"Feature: pipeline configuration from source control","user":{"login":"tomzo","id":5710970,"avatar_url":"https://avatars.githubusercontent.com/u/5710970?v=3","gravatar_id":"","url":"https://api.github.com/users/tomzo","html_url":"https://github.com/tomzo","followers_url":"https://api.github.com/users/tomzo/followers","following_url":"https://api.github.com/users/tomzo/following{/other_user}","gists_url":"https://api.github.com/users/tomzo/gists{/gist_id}","starred_url":"https://api.github.com/users/tomzo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tomzo/subscriptions","organizations_url":"https://api.github.com/users/tomzo/orgs","repos_url":"https://api.github.com/users/tomzo/repos","events_url":"https://api.github.com/users/tomzo/events{/privacy}","received_events_url":"https://api.github.com/users/tomzo/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":25,"created_at":"2015-05-16T13:57:23Z","updated_at":"2015-06-04T20:05:22Z","closed_at":null,"body":"### Motivation\r\nBeing a big fan of keeping all project-related code in its source code repository I would really like to be able to **declare pipeline configuration in the source code of each individual project** instead of the global cruise-config.xml.\r\nMany people will agree that **each project's code should know how to build and test itself**. Following this concept it should also know how to *CI-itself*.\r\n### Problem\r\nCurrently when all go configuration is in global configuration file on server we basically end up with 2 sources of projects configuration - one being git repository, the other a file on go server. There are lots of scenarios when new changes in git repo will cause the build to break because they expected different pipeline configuration. Or rather pipeline configuration expected the older git repo contents. \r\n### Concept\r\nIn order to avoid such conflicts probably the `<pipeline>` section should never be in the global cruise-config.xml, instead go-server should configure pipelines after pooling from source repositories.\r\n\r\n### Final notes\r\n * Is anyone interested in such feature or am I crazy? Please provide some feedback on how would you like to see this?\r\n * How do you (or your organization) handle the problem described above?\r\n * I am not a *gocd developer* and I am unfamiliar with its source code or development process. But I learn fast and I am very determined to get this done.\r\n * I would like to kindly ask the core developers of gocd to the right direction on getting this implemented. What components will need to be updated? How invasive would it be? Can configuration loading and applying be easily replaced to the general schema I described above."},"comment":{"url":"https://api.github.com/repos/gocd/gocd/issues/comments/109033340","html_url":"https://github.com/gocd/gocd/issues/1133#issuecomment-109033340","issue_url":"https://api.github.com/repos/gocd/gocd/issues/1133","id":109033340,"user":{"login":"tomzo","id":5710970,"avatar_url":"https://avatars.githubusercontent.com/u/5710970?v=3","gravatar_id":"","url":"https://api.github.com/users/tomzo","html_url":"https://github.com/tomzo","followers_url":"https://api.github.com/users/tomzo/followers","following_url":"https://api.github.com/users/tomzo/following{/other_user}","gists_url":"https://api.github.com/users/tomzo/gists{/gist_id}","starred_url":"https://api.github.com/users/tomzo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tomzo/subscriptions","organizations_url":"https://api.github.com/users/tomzo/orgs","repos_url":"https://api.github.com/users/tomzo/repos","events_url":"https://api.github.com/users/tomzo/events{/privacy}","received_events_url":"https://api.github.com/users/tomzo/received_events","type":"User","site_admin":false},"created_at":"2015-06-04T20:05:22Z","updated_at":"2015-06-04T20:05:22Z","body":"> However, you need older commits of the config, only for reruns of an old pipeline, right? So, I don't see why they need to be in the Go DB. Especially if all of this is happening in a plugin. I'd just get the config for that point in time using the repository itself, on demand.\r\n\r\nThat will do it. I was going for ability to rerun. \r\n\r\n> There is (and I think will be) the concept of a valid, most-fresh config (maybe not at the global level, but at least at the pipeline level).\r\n\r\nYes. But I was referring to 'refresh its notion of config' \r\n> They need to provide the commits to the config-server module, which can then take action (refresh its notion of config)\r\n\r\nI just wanted to note that we should not implement a situation when polled configuration part would **update** some configuration instance, especially CruiseConfig. \r\n\r\nI would use the static config and dynamic config separation I mentioned above. I think **server** module should be aware of that separation. config-server would only provide urls to configuration repos.\r\nThis is what I came up with after digging in code.\r\n\r\nThere is also this problem:\r\nIf there is more than one pipeline in config repo then how do we imagine rerunning just one pipeline at some older revision?\r\n\r\nBut I think it is already answered above to some extent."}}