feat: create debug actions

[im-coder-lg]

Edit the build.yml file to work for release and use debug-builds.yaml for instant files. Obviously for testing purposes, like packaging tests, etc.

[im-coder-lg]

on: push
From build.yaml

This is an issue, since we want these files only to be released as part of a release workflow. @Moosems any idea?

[im-coder-lg]

Got one. Using workflow dispatch, we can put the release version number(semantic) and push for release.

[Moosems]

on: push From build.yaml This is an issue, since we want these files only to be released as part of a release workflow. @Moosems any idea?

On release....

[Moosems]

I would instead just make a workflow and releases called Official Releases instead if you want solid ones for pushes to master.

[im-coder-lg]

I think we can use workflow_dispatch, use the variables in it and create the release maybe?

[Moosems]

?

[im-coder-lg]

We use the workflow_dispatch feature, input some variables(i.e. release version) before running the script, and when the builds are ready, the release is created but drafted, so that we can edit the release changelog, etc.

[sumeshir26]

We did a similar thing back during TimerX: link

[Moosems]

You can just make it run on release instead

[Moosems]

I guess I'm confused what the goal is here

[im-coder-lg]

You can just make it run on release instead

Yeah, we can. But it is better to enable a workflow that does the same. We can then hit the auto-changelog generation button, and voila!

[Moosems]

I guess my issue is I'm confused about what the point of it is.

[im-coder-lg]

Automation and simplification? It is easy for us to do it this way.

[Moosems]

Automation and simplification of what? The builds are already automated and to get zips just open the branch, click code, and download zip.

[im-coder-lg]

No, not that way. Using the workflows, we can enable it on demand, i. e. on release. It will draft the release, and all we have to do is edit it to put the right release name, tag and changelog. So, it is much more easier than before, right?

[im-coder-lg]

https://github.com/Futura-Py/weather/assets/76845820/0d223f9d-49ab-4881-9ff2-de30a25bc42b

Preview of the debug build workflow. All artifacts are zipped so you have to unzip before running them. This ran on my local OS, Zorin 16.2 with the base OS as Ubuntu 20.04. The glibc issue I told about can be fixed this way, so it is backwards-compatible, plus it works the same way on Jammy Jellyfish. Anyone having a computer powerful enough to test for Fedora, Arch and the like?

[Moosems]

I guess. You lead the way there. With the glibc lock, its probably something fixable with PyInstaller. I'd make a discussion over on their repo to ask for help. Rokm is pretty helpful.

[im-coder-lg]

No, it's fixed. You just needed Ubuntu 20.04 since it has GLIBC 2.31. GLIBC 2.35 is luckily backwards-compatible with GLIBC 2.31, so it's done. However, you can discuss with the PyInstaller people to figure out a way to change GLIBC locks, which I guess is hard to do.

[im-coder-lg]

I got just one more thing to do for this PR. Make the build file now run on demand, just like TimerX.

[im-coder-lg]

Just need to test.

[im-coder-lg]

Well, I guess it's fixed now! I feel the jobs might not find the runners in time, so if there is a fail, we have to rerun all jobs. But the PR is ready for review.

[im-coder-lg]

Alright, ready for review, if you exclude the fact that there are less runners for the workflow to run so it WILL fail for now.

Edit: to fix it, re-run the failed jobs.

[rdbende]

But why not simply create a workflow that runs when a repo release is published, and pull the version number from the setup.py or pyproject.toml? That would be a lot easier.

on:
  release:
    types: [published]

[Moosems]

Thats what I had recommended.