10 ms·

- you don’t need runners on remote machines unless you you have hundreds of jobs and which never happens for small or medium size dev teams - job matrix / para

- you don’t need runners on remote machines unless you you have hundreds of jobs and which never happens for small or medium size dev teams - job matrix / parallel jobs are barely needed in commercial development , only in open source , but still not in every project - pull requests and user management are coming soon

theamk 29d ago
maybe if you only do web? But not every development is web development, you know. My first job I was in ~10 people robotics/hardware startup, and we had CI cluster of about 4 workers, later extended to ~10 machines (managed by buildbot, those were the times...). And the parallel jobs happen all the time in commercial developments, no one likes to wait for a long time when they could wait for a short time. This is not done for various OS'es, instead one machine might be testing service A, while other tests service B, while the third one tests integration. That said, there is nothing wrong with "Dead Simple" niche - I am sure that there are some users who could use it. Although those would probably want something with less lock-in, your current approach is pretty weird: the jobs which _look_ like they are written in regular bash/python/etc.. but actually they have extra functions ("run_task", "task_var" etc..) magically injected, so you cannot run the file directly nor can you run linters on those. I'd much prefer pretty much anything else which can run unmodified code.
- melezhik 29d ago
  - long ci builds usually means bad code / architecture . CI should not be very heavy and should not take a lot of time. - jobs do not look like, they are indeed written on gp languages, no magic here - run_task / task_var are just SDK functions - you may or may not need them. They simplify pipelines development ( conditional tasks , getting task variables ) but you don’t have to use them if you don’t need them. There is no absolutely magic in dsci / it’s just normal programming languages - you can run pipelines locally if you really need to, however this is rarely needed and the point of having gp language for ci code is ability to use standard programming techniques, running locally is not main focus here - the main advantage is using programming languages not YAML. You can apply linters / refactoring / libraries decomposition - all standard techniques one has in gpp languages , this is always pain with YAML

theamk 29d ago

maybe if you only do web? But not every development is web development, you know. My first job I was in ~10 people robotics/hardware startup, and we had CI cluster of about 4 workers, later extended to ~10 machines (managed by buildbot, those were the times...). And the parallel jobs happen all the time in commercial developments, no one likes to wait for a long time when they could wait for a short time. This is not done for various OS'es, instead one machine might be testing service A, while other tests service B, while the third one tests integration. That said, there is nothing wrong with "Dead Simple" niche - I am sure that there are some users who could use it. Although those would probably want something with less lock-in, your current approach is pretty weird: the jobs which _look_ like they are written in regular bash/python/etc.. but actually they have extra functions ("run_task", "task_var" etc..) magically injected, so you cannot run the file directly nor can you run linters on those. I'd much prefer pretty much anything else which can run unmodified code.

melezhik 29d ago
- long ci builds usually means bad code / architecture . CI should not be very heavy and should not take a lot of time. - jobs do not look like, they are indeed written on gp languages, no magic here - run_task / task_var are just SDK functions - you may or may not need them. They simplify pipelines development ( conditional tasks , getting task variables ) but you don’t have to use them if you don’t need them. There is no absolutely magic in dsci / it’s just normal programming languages - you can run pipelines locally if you really need to, however this is rarely needed and the point of having gp language for ci code is ability to use standard programming techniques, running locally is not main focus here - the main advantage is using programming languages not YAML. You can apply linters / refactoring / libraries decomposition - all standard techniques one has in gpp languages , this is always pain with YAML