Ghidra: Continuous integration

[devnoname120]

Ghidra's build process is not very straighforward. Also the code base has tests, which should be run against every pull request to make sure that they don't introduce any regressions.

For these reasons, I'd be interested in adding support for a CI system such as Azure Pipelines or CircleCI (both are free for OSS). There are many other promising CI services like Bitrise but I favor established services that are likely to stick around for a long time.

Would you be open to enable one of these services on the repository if I contribute a CI config file?
I want to make sure that it would be okay for you before spending time on making them work.

[nightlark]

One of the first things I checked when I saw that the code had been released was a badge in the README or at least a config file for a CI system (Travis, Azure, etc).

[Ristovski]

I agree with Ghidra having a not straighforward build system. It seems like all the dependencies that have to be downloaded "manually" make things quite tedious.

I wonder if this can be improved, even though I don't think it would be possible to have a master gradle build that would build Ghidra with all the bells and whistles due to it's shear complexity (maybe not impossible but very hard to implement).

[emteere]

The gradle build could be modified to automatically download all the dependencies.

The decision was made to have the end builder download the dependencies that were not pulled from a standard maven repository. This was partly to make sure the end builder was aware of the individual components, the dependency locations could potentially change, and to get the source out as soon as possible ;-)

In addition there is a need to balance each builders trust in any automated build system. Ghidra was an internal project with a standalone build system, and relying on external resources must be done with care. Currently you could pull all the build artifacts and then build them on a disconnected system, or setup a CI system on a simple system without depending on an infrastructure. That said, there is always room for improvement and CI is high on the list; done with knowledge of the pros and cons of the individual CI system.

[ryanmkurtz]

I would hold on off any kind of CI contributions. We need to first figure out what will work for us long-term both internally and externally. Once that is in place, I'm sure there will be plenty of room for contributions.

[devnoname120]

@ryanmkurtz Ah I see. Note that the CI system used internally does not need to match the CI system used for open-source contributions.