You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add option for Build workflow to push compiled binaries to the repository. #37
Many mods that have their focus mainly on parts, say BDB, Tundra or SEP usually have their dll’s in the repository.
Recently when I set up BCS I put the dll in the gitignore since binary files can’t by merged and it could lead to the dll not being inline with the source if two branches got merged around the same time, both stemming from the same commit on main.
Users who like to be on the bleeding edge then clone the repository and are left without a plugin.
It would be nice if the build workflow could be configured to commit the binary file it builds into the repository so it can be left in the gitignore but still kept up to date in the repo.
I understand that the artefacts would be the place to get it. But those only stay for 30 days I believe, plus they do not get updated upon non code changes.
a pre-release is an option, one that already exists for BCS but like with the previous solution, that’s not what users are used to and you can’t expect them to magically change that.
Sofie's changed my mind and I think if mod devs want to commit their build artifacts we should let them. In particular it enables advanced users to clone the repo in order to get incremental updates for large mods like BDB. I'm less thrilled about normalizing users who click the "download code zip" button in order to get bleeding edge stuff, but it is what it is.
As a weak proposal, the compile action should just git add and commit if anything changed. If build artifacts are in the .gitignore, this would be a no-op.
Or perhaps it should be opt-in with a list of files/paths to add and commit?
Activity
JonnyOThan commentedon Oct 18, 2024
You can’t commit something that is in the gitignore.
Users who want to be on the bleeding edge should download the artifacts from the actions page.
Other reasonable options might be to always publish a prerelease with the latest build.
SofieBrink commentedon Oct 18, 2024
That’s not necessarily true, see here
I understand that the artefacts would be the place to get it. But those only stay for 30 days I believe, plus they do not get updated upon non code changes.
a pre-release is an option, one that already exists for BCS but like with the previous solution, that’s not what users are used to and you can’t expect them to magically change that.
drewcassidy commentedon Oct 18, 2024
Could make the workflow run every 30 days
JonnyOThan commentedon Oct 18, 2024
both of these are totally up to the repository
JonnyOThan commentedon Oct 18, 2024
I’d rather lean into prereleases, especially if something like this ever gets implemented: KSP-CKAN/CKAN#4159
SofieBrink commentedon Oct 18, 2024
Alright, guess we’ll put it in big bold text in the readme not to clone the repo then
JonnyOThan commentedon Oct 18, 2024
JonnyOThan commentedon Oct 24, 2024
Sofie's changed my mind and I think if mod devs want to commit their build artifacts we should let them. In particular it enables advanced users to clone the repo in order to get incremental updates for large mods like BDB. I'm less thrilled about normalizing users who click the "download code zip" button in order to get bleeding edge stuff, but it is what it is.
As a weak proposal, the compile action should just
git addand commit if anything changed. If build artifacts are in the .gitignore, this would be a no-op.Or perhaps it should be opt-in with a list of files/paths to add and commit?
drewcassidy commentedon Oct 24, 2024
Or anyone who wants this can implement it themselves. It’s not that hard to add the git push step to the end of a workflow