As the sole maintainer of mc-modpack-kit, I've encountered significant challenges in managing this GitHub Actions "template" project. Recently, I've been struggling to allocate sufficient time for its maintenance.
Please note: While I will continue maintaining this template for the time being, it's unlikely to be a long-term solution. I prioritize addressing the issues at hand first.
1) Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in.
2) Configure with github actions. Always ask yourself "can I push this YAML complexity into a script?" and do it if you can. Send an email? Yes, that can go in a script. Your workflow ends up being about 50-60 lines as a result and very rarely needs to be changed once you've set up. Github actions is suddenly fine and you rarely have to do that stupid push-debug-commit loop because you can debug the script locally.
For a detailed exploration of these issues, check out this video:
Moving Forward with Nix
Given the challenges posed by maintaining a GitHub Actions project, I'm considering a shift towards Nix, which has gained popularity recently. This move offers several advantages, including:
Declarativity: Nix provides a declarative approach, which aligns well with modern software development practices. This contrasts with the procedural nature of GitHub Actions YAML files.
Benefits of Nix Integration
Simplified Maintenance: By leveraging Nix with GitHub Actions, we can streamline our workflows and avoid the complexities inherent in managing sprawling YAML configurations.
Version Pinning: Instances like issue #72, where dropping older versions caused inconvenience, can be mitigated through better version control and pinning offered by Nix.
The other actions like bumping versions could be simplified.
A robust but simple pipeline could be achieved.
And as @logamaster said on the Discord:
I say make a simple one file action.
It just reads a release from github and pushes the result.
So using the tag value, push to Modrinth and CurseForge or when a tag is pushed build and set up the result.
This could be done with nix
Considering the challenges in managing a GitHub Actions project, I'm contemplating exploring alternatives like Nix, though the extensive rework required raises concerns about time constraints at least for me, since I have other stuff to do.
Challenges in Maintaining
mc-modpack-kitAs the sole maintainer of
mc-modpack-kit, I've encountered significant challenges in managing this GitHub Actions "template" project. Recently, I've been struggling to allocate sufficient time for its maintenance.Please note: While I will continue maintaining this template for the time being, it's unlikely to be a long-term solution. I prioritize addressing the issues at hand first.
The Problem with GitHub Actions Complexity
As someone on HackerNews points out:
For a detailed exploration of these issues, check out this video:
Moving Forward with Nix
Given the challenges posed by maintaining a GitHub Actions project, I'm considering a shift towards Nix, which has gained popularity recently. This move offers several advantages, including:
Benefits of Nix Integration
The other actions like bumping versions could be simplified. A robust but simple pipeline could be achieved.
And as @logamaster said on the Discord:
Considering the challenges in managing a GitHub Actions project, I'm contemplating exploring alternatives like Nix, though the extensive rework required raises concerns about time constraints at least for me, since I have other stuff to do.