Incorporate GitHub Actions to create new releases #65
Comments
|
Sounds good to me! |
|
@rluzuriaga I just stumbled upon an interesting difference when building with GH Actions: But when manually building from the latest I see this: Looks like it's unable to use our existing configs.... |
|
Same with the kernels: |
|
@Sebastian-Roth That's odd. When I run it manually I get the exact same output as GitHub Actions. I just thought that was the normal process. |
|
@rluzuriaga said:
Exactly as seen above: |
|
@Sebastian-Roth Oh maybe it's an Ubuntu thing. I'll look into it. |
|
I am just worried about the "Restarting config" message and I guess the "Error in reading or end of file" is part of that as well. I am not exactly sure but I guess this happens when you run |
|
@Sebastian-Roth So I created a brand-new Debian 11 VM to test the difference in building between it and Ubuntu.
|
|
@Sebastian-Roth Okay I did some more testing and the same appeared on Debian 11 and 10. I tried Debian 9 and then I get the same output as your local machine. Is the machine running Debian 9? |
|
@rluzuriaga Right, got me there! Using an old Debian 9 system for building. I will test on an up to date system soon. I think we can just leave this topic open for the time being. I will get back to it when I have more time. Thanks heaps for your testing! |
|
@Sebastian-Roth I think I know why Debian 9 doesn't give that "issue". When building the kernels and inits on Debian 9 or Ubuntu 18.04 and bellow, it doesn't ask for the following packages. On newer versions of Debian and Ubuntu we would need to add these 4 lines to the filesystem config files. MPD (Music Player Daemon) shouldn't be needed neither should nodeJS or QEMU. These are the lines that need to be added to the kernel configs. x64 Kernel Configx86 Kernel Configarm64 Kernel ConfigHow did I get these configs? It's just the default that the builder gives. |
|
@rluzuriaga I just updated the kernel and buildroot configs to build on Debian 10 without those messages (9632dcc). We should definitely be aware of those changes (mentioned by you as well): I think it's ok to enable those but we need to keep that in mind in case people complain about issues with the 32 bit kernel. |
|
@rluzuriaga To be sure we don't miss this kind of config changes we need to make sure we are using the same OS and version when preparing the configs as the Github Actions. I am wondering if it's wise to set Currently |
|
@Sebastian-Roth I agree, I'll change it to 22.04. I think that as soon as a new LTS version comes out, we should try building on it so that we don't fall behind. Since I'll be making this change, I could make the changes so that the Kernel and Buildroot versions are automatically retrieved from |
|
@Sebastian-Roth I also saw this commit that you made to |
|
@rluzuriaga said:
Yeah, that'd be great. I can't see why we would need manually enter that information. If it needs adjustment at some point (e.g. we want other tag names), then we can simply change the YAML again. Great!
Sounds great as well. I think adding a checkbox (default unchecked) and an extra field named "Release Version" would work perfectly fine. |
|
@rluzuriaga As well you can remove the "Pre-release" checkbox. While it can be useful I think it can confuse people as well now that we add the "Official release" checkbox. On the Github fos releases page we can manually edit a release and change it to pre-release if wanted. The only case this is playing a role is, that pre-releases are hidden from the FOG web UI kernel update view. |
|
@Sebastian-Roth Sounds good to me. Maybe it is a good idea to change the release name to full date. Instead of For the official release checkbox, I would have to add a text field for the release name/FOG version, since there is nowhere in the code to get that info. |
|
If changing the format, should it be YYYY-MM-DD? This way we can see at a
glance what is newer
…On Mon, Mar 13, 2023, 6:22 p.m. Rodrigo Luzuriaga ***@***.***> wrote:
@Sebastian-Roth <https://github.com/Sebastian-Roth> Sounds good to me.
Maybe it is a good idea to change the release name to full date. Instead of
MM.DD.YYYY it could be MONTH DD, YYYY?
—
Reply to this email directly, view it on GitHub
<#65 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTQQFUG7B4VMMFO4E7SAVLW37B57ANCNFSM6AAAAAAU4HPJ5A>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
@rluzuriaga said:
I side with the format @lukebarone suggested,
Yes, would need an extra text field. |
I think the best way to incorporate GitHub Actions is by having a manual workflow.
The manual workflow would have a few questions to fill out the release information.
Have it look something like this:
The workflow would build all kernels and buildinits, then upload them to the release.
The text was updated successfully, but these errors were encountered: