431–440 of 468 posts
Earlier quoted context omitted.
> 4. Do you just want to host repositories?
Yes it is not so straight forward to be able to push/pull from a repository over ssh especially with multiple users etc there are a bunch of additional configs required for this
Earlier quoted context omitted.
I migrated my Gitea instance to Forgejo, it was pretty painless
I accidentally upgraded my Gitea instance beyond the fork which makes this more difficult...
Earlier quoted context omitted.
The whole "social coding" angle is highly off-putting. List of "X followed Y" on the front page, and the large "social coding" reminds of facebook, social manipulation, developer burnout and all the negative things about social networks. It also brings up the questions about project's long-term direction - is this going to focus on the code part or the social part? Which is a pity - as I think most projects just need…
Arguably the "social coding" angle is the reason why Tangled is the only actual alternative to GitHub. Otherwise there's actually plenty of other alternatives to GitHub, but none of them have GitHub's punchcard, which I'm ashamed to admit is the primary draw for me.
Earlier quoted context omitted.
- 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
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…
- 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
I have a pretty bad taste in my mouth from GitHub, GitLab, Forgejo, Gitea, etc. They all attempt to hijack Git itself and become a monolith and single custom interface, rather than independent components that work around the Git repo. I want the Unix philosophy applied to Git and other functions. That way I'm not forced to switch the entire kitchen sink out when some single piece of functionality or hoster ends up br…
Sounds like the description of Radicle. :-) https://radicle.dev/guides/protocol#collaborative-objects
What I want is a system that doesn't define functionality. I want something protocol-less. The larger system design prescribes only loose i/o channels between components, so (for example) you know you can interrogate something Git-ish. But what language or protocol they speak, what functionality they contain, isn't prescribed by the design. This allows them to have any functionality.
You might think I want something like microservices. But microservice interfaces are too prescriptive and not interoperable with other services. Everyone writes their own custom incompatible API for the same basic functionality. What's needed is something so simple, so loose, that people naturally copy the first one they see for their own implementation.
Example: Pull Requests. They're basically just a git diff, that can be approved, blocked, rejected, and comments are attached to them. You could implement that a hundred different ways. But what's the simplest possible thing? It already exists: patches in e-mail. You e-mail a diff to a mailing list, people reply (comment) on pieces of the diff, and eventually somebody commits and merges some form of the diff and pushes it to their repo. You didn't really need a DAG, or objects, or CRDTs, or protocols. You already had everything you needed. So how to implement this, in a system with no protocols? Just feed e-mails into an app; the app reads the e-mails, it accesses a clone of a Git repo for operations, it sends e-mails out, and displays comments etc in a web interface of the diff.
Next example: Issues. This one is pretty simple: use any ticketing system you want, the rest of the system has no idea. Reference an issue's URL in a comment or commit message with either the bare url, or markdown ([issue #123](uri://somehost/issuetracker/view?i=123)). Use OIDC to allow logins, or read-only for anonymous.
Want to "copy" data from one system or component to another? Each system can do this differently, but if you make it simple enough, they'll all do the same thing. Simplest solution? For each service's HTTP endpoint (I'm just assuming they would all use HTTP to communicate, but don't have to), prefix the endpoint with "/zipmime", and the result is a ZIP file of MIME files (so "uri://somehost/issuetracker/view?i=123" becomes "uri://somehost/zipmime/issuetracker/view?i=123"). Now you can export any data from any service in a standard way that supports any kind and amount of content (because it's URI-based and HTTP-based, the service doesn't even have to support this natively! you can implement a reverse proxy and microservice to bolt the functionality on later).
At no point in any of these designs are they dependent on other designs. They just "do what they do", and other designs naturally coalesce around simple standard methods.
Earlier quoted context omitted.
Classic CI vendors like Semaphore, Circle, etc are options.
I feel like something is missing from your list of "classic CI vendors" but can't exactly jput my jfinger on jit.
Files of any size, centralized, and easy to use.
Earlier quoted context omitted.
I feel like something is missing from your list of "classic CI vendors" but can't exactly jput my jfinger on jit.
I think of Jenkins as a project, not a vendor. (if you're looking for alternatives to Github, I'd assume it being a managed solution is a requirement)