DSCI project - ci runner with general programming languages

Hey! :waving_hand: dsci author here

Dsci is general programming languages based ci integrated with forgejo web hooks, wonder if maybe code floe devs take a look at it, and maybe it can become a part of code floe service as well , I am open for discussion

@sp1983 Thanks for reaching out!

As you’ve noted, CF has already two integrated CI systems - Crow CI and Forgejo Actions. Right now we don’t see much added value adding a third one. Adding a new one also comes with additional administrative burden such as installing the server part, maintaining runners, sharing existing resources with the other CI systems, ensuring they don’t clash with each other, etc.

Besides these, we don’t really feel that dsci is yet a mature software yet - looking at the commit history, it is a (still young) one-person project which hasn’t seen any commit between February and July. This raises questions about it’s general and long-term development state. Furthermore, it doesn’t publish release binaries yet, is lacking a dedicated docs page, comes with a rather “hacky” commit message approach and seems to quite “bare bones” in its general approach on CICD.

Quoting from the README:

No clunky YAML/Terraform/Ansible - just old good Python/Bash scripts

should likely be a feature in the context but is rather a strong limitation in our view - there are reasons why CICD pipelines use YAML configuration files and inherit a medium-strong complexity. On top, CodeFloe makes heavy use of Ansible and Terraform for its infra and doesn’t view them as “clunky” at all.

Sorry, that we cannot give a more positive reply here, but maybe our honest take is also worth something here! We wish you all the best and a lot of fun on the future development of dsci but we don’t think it’s a good match for CodeFloe as a platform for the various reasons outlined above.

Hi and thanks for your response. I am not sure who I am taking talking to, I assume the founder of the CF, as you are referring to the email I send to Patrick today with the same proposal, anyways I find it’s respectful to sign your reply and not answer anonymously

I did not ask you to evaluate or asses my tool, only proposed on possible collaboration , and cause you made some judgements and pretty strong statements on the quality and concept of the dsci , here is my short reply , I am writing it here only because you made those statements in public and I feel it’s quite fare from my side to make my response as well , though such a discussion about dsci itself was not my original intention and I don’t expect further replies from your side here, so feel free just close the topic afterwards

Anyways:

  • not sure what you mean by hacky commits messages , I find it weird to judge a quality of software by commit messages , I have seen some terrible software with nice and clean commit messages and vise versa
  • the same thing on the number of commits and having just a single maintainer on the project - does it correlate to the quality or maturity of the project ? I am no sure. ( Linux started as one man , haha ) Dsci is good enough right now. If it gets traction and gain new users - of course it will grow in codebase and probably get new contributors, don’t be too judgmental here
  • Terraform, Ansible, YAML and friends - you probably should have read more into context and then may get more clear why those tools may become pain in a neck , but I am not sure you would want
  • Using general programming languages not just YAML ( which has a reasonable amount and context in dsci as well ) is advantage not limitation
  • Dsci does have good documentation I am abit surprised you have not found the one - you may look up all the markdown docs in the respected GitHub repository

All the best

The dsci author

UPDATE; if I play your game ) there is just a one committeer for example in this repo - https://codefloe.com/codefloe/infrastructure-as-code ))

We didn’t refer to any email in our previous reply.

You are talking to the platform account as you’ve made a request to the platform itself.

You asked us to deploy your tool, so it’s fair in our view to share our thoughts about our decisions. Some people value that, others don’t. We could also have just replied with “no, thanks” or not at all as an alternative - whatever way one is choosing, it’s (most often) always perceived wrongly :slight_smile:

By this we mean non-descriptive commit messages that relate back to edits made in the browser directly. These are the norm in the dsci project, not the exception.

You’re maybe taking this a bit too personal. Many projects have a single maintainer only, also others in use at CodeFloe. There are many aspects in this subtopic and we don’t wanna go too deep here - if you’re happy with the state and the project overall, that’s great!

Thanks, but we are very convinced about the positive aspects of these.

Single markdown docs aren’t what makes a good documentation to everyone.


All the best to your project, thanks for reaching out and sorry for sharing so many thoughts of ours which seemed to not have been perceived so well on your end.