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

Archive nightly builds #12

Open
sdasda7777 opened this issue Aug 15, 2023 · 8 comments
Open

Archive nightly builds #12

sdasda7777 opened this issue Aug 15, 2023 · 8 comments

Comments

@sdasda7777
Copy link

Would it be possible to archive the nightly builds somehow? Not only are the actual releases long outdated, without having easy access to all the different version over time, it is actually really hard to figure out when exactly something broke (e.g. #11).

@sdasda7777
Copy link
Author

@JanBliznicenko ?

@JanBliznicenko
Copy link
Member

Hello, it would be possible, but it would require reworking the build script and, what is more important, I believe it would spam the repo quite a lot with many builds that would never be used even a single time. I think if you need to look, let's say 3 months back, link Pharo to local git repository (or repositories, if the same is needed for more than just OP core) then checkout older commit. What certainly is true that the actual releases are very outdated and the frequency should be heavily increased.

@sdasda7777
Copy link
Author

Yeah, I guess it's true there would be a lot of them. I know you can set the workflow to just create a build on every commit/push, so the archived builds would be "hidden" in CI section of each commit, which would still definitely be helpful, but it's not ideal when there are so many dependencies which are all changing between each commit (or especially after the fact), and I'm not even sure how it would be implemented in a project spanning multiple repos. Larger projects usually have some sort of artifacts storage for that (such as VLC's), so the nightly builds and releases are clearly separated, but I don't really assume that is within the realms of possibility here.

@JanBliznicenko
Copy link
Member

JanBliznicenko commented Oct 7, 2023

I have gone the most simple-yet-sufficient route of publishing the files here on GitHub, but having separate pre-release for every commit would create too many of them I think.
If you have any idea how to do it somehow nicely and time to try that, I can give you access.
What is currently going on is that on pushing to master, workflow nightly.yml is run that builds all zips, re-creates the nightly pre-release, uploads those new zips there and trigger builds of all dependent repositories (so for example OpenPonk-BPMN build triggers plugins build).
All other repos that publish builds (like OpenPonk-BPMN, petrinets etc.) use nightly.yml from this OpenPonk/plugins repo.

@sdasda7777
Copy link
Author

sdasda7777 commented Oct 7, 2023

Hmm, yeah, I understand. Would it perhaps work to have a separate repo to store the nightly builds in (as a set of "versioned" files for each build) (OpenPonk/builds-archive, or similar), with the latest ones also being here (as releases), as is currently the case?

@JanBliznicenko
Copy link
Member

Unfortunately, storing large amount of large files using git is generally not very good idea. It requires using LFS and GitHub.com could actually require making the total repo size smaller. It is not that much of a problem when storing files as part of releases.

@sdasda7777
Copy link
Author

Well, I believe I remember seeing a repo like this, but I can't remember the details. However, does that mean that having a repo where the builds would be archived as releases would work?

@JanBliznicenko
Copy link
Member

JanBliznicenko commented Oct 9, 2023

I believe it might. Best solution would be a proper deployment storage / content delivery system with filtering by release type etc., but that would require money, time or both and there is not much of either :D

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

No branches or pull requests

2 participants