Build scripts and Nitrocid

We are still making improvements to the build script as part of our promise about building better projects. Build scripts are one such effort where we try to make the build scripts unified across all platforms. You can build projects like Nitrocid, Terminaux, and BassBoom, using just a single short command. For Linux and macOS users, building with default configuration is just four letters away: make.

The evolution of the build scripts started back in 2021 when we had first made them available as buildandpack for both Windows and Linux systems. These scripts were not CI-friendly due to the read prompts, and CI doesn’t support read prompts. Back then, we were using Nitrocid as the testing ground as you can see in this commit while we were developing 0.0.19.0.

0.0.21.3 had seen a new script, called docgen, that wrapped around the DocFX documentation that we are still generating for all our libraries and applications to this day.

During the development of 0.0.24.0, the build scripts were made to support automation, along with being split to multiple functions, such as build, pack, and push, to make working with CI easier. Since then, those build scripts were copied to all libraries that are currently being used presently.

Today, we are proud to announce that our build system is almost ready to go, and that Nitrocid is currently using it, but we need to make some tweaks to ensure that we provide seamless experience for all users. The documentation will land to our GitBook to give you a head start.

#BuildScript #news #nitrocid #Technology #update

Build System Refinement

We are currently in the process of refining the build system so that developers can build our projects more efficiently than before. The build scripts will be updated so that they reflect what we plan to do to them, such as being able to be run from any working directory for complex build procedures.

This will save time for both the developers and for those who plan to contribute to our projects. The update to the build scripts will be rolled out gradually as we evaluate choices to make sure that those scripts meet our quality requirements. The development branches of Nitrocid and Terminaux are the testing grounds to develop the updated build scripts.

The GitHub workflows will also be updated to more accurately verify our work by introducing dry running to all the scripts. This way, we’d be able to deploy the release more efficiently without having to create errata releases for just one minor build issue. For example, Nitrocid 0.1.2.1 had to be released after we’d discovered that the NuGet packages for 0.1.2.0 were missing due to a failing step related to the Discord webhook.

We’ll apply the appropriate changes based on the impact, and we’ll make sure that the developer experience of contributing to our projects will be much better. Much, much better than before.

Photo by ThisisEngineering on Unsplash

#build #BuildScript #BuildScripts #BuildSystem #msbuild #news #nitrocid #Tech #Technology #terminaux #update

ThisisEngineering (@thisisengineering) | Unsplash Photo Community

See 380 of the best free to download photos, images, and wallpapers by ThisisEngineering on Unsplash.

Did you ever just want your #gradle #buildscript to deploy executables and dependencies from multiple software projects to multiple servers?

And did you bang your head against a wall because the documentation is not up-front about how to do that?

Fear not! Help is here!
https://gist.github.com/aev-mambro2/e080ea2d52126c3b701a1cd43400dd58

How to deploy from multiple projects to multiple target servers using Gradle CDCI

How to deploy from multiple projects to multiple target servers using Gradle CDCI - gradle-deploy-multiple-projects-to-multiple-targets.gradle

Gist

Looking to use #Gradle for building software projects and testing / deploying them as part of your #CICD pipe lines? I have 5 years of experience with Gradle, which culminated in the following draconian #buildscript: https://gist.github.com/aev-mambro2/2c39b30ee1b326325c8c665bde2a7d39

Gradle used to have a ton of rough edges that I hope have been smoothed out over the years. But I have not upgraded in 2 years (because every upgrade would break something else). So maybe some of my defenses can be removed?

build.gradle

build.gradle. GitHub Gist: instantly share code, notes, and snippets.

Using #gradle with #EclipseIDE is seriously painful.

If you make a mistake in the #buildScript, and have Eclipse's automatic project rebuilds active, and have Gradle's automatic project updater active, they get into a build failure loop that simply doesn't end.

I've had this happen every single time I need to upgrade Gradle, and plenty of times when creating a new project based on a gradled template.

It happens in multiple versions of gradle and Eclipse. :(