Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI: monthly build, ability to manually trigger GitHub Actions for specific Ghidra versions #26

Merged
merged 6 commits into from
Sep 18, 2024

Conversation

SmileyAG
Copy link
Contributor

Closes #21

  • Replaced compilation for multiple Ghidra versions with the latest version
  • In addition to the change above, the ability to specify the version(s) when manually triggering GitHub Actions was added (so that anyone who wants support for their version of Ghidra from the latest master only needs to fork the repository and choose to build the desired version, perhaps this should be noted in README.md, idk)
  • Added a monthly build (this is in case the current code became incompatible when building with the latest version of Ghidra or if something in the CI itself broke, like outdated versions of actions)

@antoniovazquezblanco
Copy link
Contributor

A couple of comments:

  1. I don't see the need to build monthly, the project should be built when changes are commited. Why do you want to build periodically?
  2. Compiling for different Ghidra versions is positive for me. Plugins may not be compatible between versions and this helps tests that and produces releases for all the compatible apis. Why delete that?

Thanks!

@SmileyAG
Copy link
Contributor Author

I don't see the need to build monthly, the project should be built when changes are commited. Why do you want to build periodically?

It really makes sense to do a monthly build to check that the current code still builds successfully with the latest version of Ghidra, secondly, to check if some of the other actions are outdated and maybe they should be upgraded or their parameters changed (at a minimum, this can only cause warnings, at most, CI will start giving an error during the build), thirdly, if a lot of changes were made, and there was no official release, then this will allow you to still get the current unreleased version, in addition, in GitHub Actions, artifacts can be stored for up to 3 months from the moment of their build, after which they become unavailable. So in a monthly build there are only advantages from this, I was convinced of this when working with CI in other projects. Just think of it as a kind of preventative measure.

Compiling for different Ghidra versions is positive for me. Plugins may not be compatible between versions and this helps tests that and produces releases for all the compatible apis. Why delete that?

I can return the rest of the versions, but it seems to me that it is not very good to make 8+ or so builds per each trigger (push, pull_request, workflow_dispatch), when we can only build for the latest version and maybe a few more that are important to us, and those who need to build for their version can simply fork the repository, go to Actions, enter the desired version in the field and start the process - it's literally a couple of clicks and you don't need to change anything in the CI code, literally anyone can figure it out (we can leave a note about this in README.md if needed):

exp

@ubfx
Copy link
Owner

ubfx commented Sep 14, 2024

I also think the automatic build for a set of (reasonably) recent ghidra versions makes sense. Since github hosts the runner and artifacts, I see no issue with having a bunch of runs triggered each time. If this saves a user some time and hassle, that's a worthwile investment.
But having an additional periodical build against "latest" ghidra version can't hurt either.

@SmileyAG
Copy link
Contributor Author

Yeah, it all makes sense now. In general, the model to compile the latest build version, a couple of stable build versions up to a specific version and also to have the optional ability to try manually build for the specified versions in a few clicks - sounds so perfect. This should clearly be enough.

Copy link
Owner

@ubfx ubfx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you

@ubfx ubfx merged commit a9edd7a into ubfx:master Sep 18, 2024
9 checks passed
@SmileyAG SmileyAG deleted the ci branch September 27, 2024 11:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add a CI workflow using GitHub Actions
3 participants