-
You can also find many leftovers with the "VSS" acronym, like https://github.com/actions/runner/blob/main/src/Sdk/Common/C... or https://github.com/actions/runner/blob/main/src/Sdk/Common/C... - which also mentions TFS (which is yet another acronym that used to refer to the Microsoft team-development thing).
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
I feel I'm being trolled, but I'll bite and accept the resulting downvotes
I don't think treating every mention of act as an opportunity for airing of personal grievances is helpful in a discussion when there's already ample reports of people's concrete issues with it, had one looked at the 800 issues in its repo https://github.com/nektos/act/issues?q=is%3Aissue or the 239 from gitea's for https://gitea.com/gitea/act_runner/issues or whatever is going on with Forgejo's fork https://code.forgejo.org/forgejo/act .
But, as for me specifically, there are two and a half answers: I wanted to run VSCodium's build locally, which act for sure puked about. Then, while trying to troubleshoot that, I thought I'd try something simpler and have it run the lint job from act's own repo <https://github.com/nektos/act/blob/1252e551b8672b1e16dc8835d...> to rule out "you're holding it wrong" type junk. It died with
[checks/lint] Failure - Main actions/setup-go@v3
-
action-tmate
Debug your GitHub Actions via SSH by using tmate to get access to the runner system itself.
You might also be interested in https://github.com/mxschmitt/action-tmate, which enables SSH to workers for debugging. If you have trouble reproducing issues on CI, this can be a life saver (or at least save a few hours of commit-push-wait rounds).
-
windmill
Open-source developer platform to power your entire infra and turn scripts into webhooks, workflows and UIs. Fastest workflow engine (13x vs Airflow). Open-source alternative to Retool and Temporal.
We have built an open-source generic workflow engine to run arbitrary scripts (https://windmill.dev) with a vscode extension to build the yaml using a low-code builder and each individual script in their dedicated python/ts files so you get your full editor assistants https://youtu.be/aSOF6AzyDr8?t=116
One of the area we are expanding next is a github app so you get exactly the same UX as github actions but running windmill workflows on your windmill workers.
-
BrowserBox
🌀 Browse the web from a web page. Remote browser isolation. For security, privacy and more! By https://dosyago.com
-
* Gitlab EE (enterprise edition) is closed, but Gitlab CE (community edition) is open source (https://gitlab.com/gitlab-org/gitlab-foss/)
* I didn't follow the Gitea drama too closely, but my understanding is that Forgejo was a fork born out of that situation
* I've heard the SourceHut guy is a controversial figure, so avoiding it because of that isn't unreasonable. I will just say that "spite forks" tend not to last very long
-
Good luck running this locally. There's no script code to speak of, just references to external "actions" and parameters (for example, https://github.com/docker/setup-buildx-action).
Some CI platforms are just a simple glue layer (Gitlab CI - which I prefer - is one of them), but in most cases Github CI is not. Maybe it adds to the author frustration?
-
> 2. To test/debug CI jobs, use act.
I can't wait for this meme to die, or for act (or gitea's fork thereof) to catch up to the hype train. Then again, I guess this fantasy is being promoted by folks who are all "just use run: and that's it" because any moderately complex one <https://github.com/VSCodium/vscodium/blob/1.84.2.23314/.gith...> for sure fails with spectacularly illegible error messages under both act and gitea's fork
-
garden
Automation for Kubernetes development and testing. Spin up production-like environments for development, testing, and CI on demand. Use the same configuration and workflows at every step of the process. Speed up your builds and test runs via shared result caching
Yes, there's us over at https://github.com/garden-io/garden! We're big believers in pipelines that run anywhere. I even made a short little video that should give you the gist. [1]
Some of the short-list of differences: we use YAML for our configuration language, Dagger can use full-fat languages to define its pipelines. Our feature scope is broader: you can use us to vend IDP-like stacks to your developers if you're a Platform Team; we make development with remote Kubernetes clusters very easy, including all the remote image builds; and we have a number of integrations so you can bring your IaC tool of choice (Pulumi, Terraform) into your pipeline and set up service -> infra dependencies.
[1] https://www.youtube.com/watch?v=JFnan6s2cDg
-
The non-video TruStacks link: https://github.com/TruStacks/trustacks#trustacks-software-de... (Golang; GPLv3)
The non-video Gale link: https://github.com/aweris/gale#github-action-local-executor (Golang; Apache 2)
-
The non-video TruStacks link: https://github.com/TruStacks/trustacks#trustacks-software-de... (Golang; GPLv3)
The non-video Gale link: https://github.com/aweris/gale#github-action-local-executor (Golang; Apache 2)
-
Not sure if related, but recently read about https://github.com/Cicada-Software/cicada which looks like to abstract GithubCI and GitlabCI.
-
> GitHub Actions is based on Visual Studio Team Foundation Server's CI, and later Azure DevOps
Yes and no, ADO Agent (https://github.com/microsoft/azure-pipelines-agent) is far more secretive and "black-box" alike.