C::B Github Actions build information

[AndrewCot]

I have successfully got C::B building automatically on the following Github repo on push and pull_request for Linux and MacOS at the moment:   https://github.com/acotty/CodeBlocks_Unofficial_Testing/actions

All of the bits required to get Windows building using the github actions are in the repo using a very similar process to Linux, apart from the deb step as the repo has the changes to build windows using the bootstrap/configure/make process.

[AndrewCot]

If you need to work on Github actions then you may want to check out the following repo as it allows you to test the workflow and steps on your PC instead of github:

• https://github.com/ChristopherHX/runner.server

In order to checkout wxwidgets repo you will need to do the following:
a) Create a a Personal Access Token
b) Create a .secrets file with the following line in it:

• GITHUB_TOKEN=replaceThisTextWithYourPersonalAccessToken

The following is the command line I have been using to test the Windows workflow on my Windows 10 PC from a windows command prompt:

• .\bin\Runner.Client.exe --workflow .github\workflows\Windows-continuous-integration.yml --event push --payload CB_test.json -P windows-2019=-self-hosted

The CB_test.json file is:
{
    "inputs": {
        "x": "Hello World from event"
    }
}

[ollydbg]

Nice work!

But this is a complex task for me. 

Can you open the issue system in your git repo:  acotty/CodeBlocks_Unofficial_Testing: Unofficial GIT clone of C::B repo in SourceForge (maintained by C::B developer, accepts patches or pull requests)

So that people can discussion issues here.

Once you have finished the Windows build action tweaks, I will fork and try it. 

[AndrewCot]

I have enabled issues and discussions.
I have been fighting the Windows github actions for days now and have made allot of progress, but have not got C::B building.

The wxWidget build script has a work around for a bug in wxWidget where it does not create the /lib/gcc_dll/mswu/wx directory if -j is not 0 when doing the "mingw32-make.... setup.h" step. I have raised an issue (https://github.com/wxWidgets/wxWidgets/issues/22435), but it was closed as it was a dup of 14470 that has been open since 2012!!!! yes 10 years old and a such I do not think it will get fixed.
The bash scripts have a allot of error checking, but could be re-worked to move code into functions to make it more maintainable.
Once I have the workflow building C::B I will then post that it is building. I will then need to look at the next stage of packaging the build (for Linux, MacOS and Windows) and then saving the artifacts (results). I will only package and upload the artifacts on a Git tag.

[AndrewCot]

I finally have C::B windows building on Github actions, but it takes ages (3hrs) in total from start to generating the C::B exe. It does not include generating the installer as this step is failing. If anyone can help reduce the time I would gratefully appreciate the help, but be aware that building locally and building on Github are not the same as the Github environment is a 2xCPU virtual Windows 2019 machine.

Next to start working on the installer step and then work on the packaging for Linux and MacOS.

[ollydbg]

I finally have C::B windows building on Github actions, but it takes ages (3hrs) in total from start to generating the C::B exe.

Good!
But, 3 hrs is too long. 

It does not include generating the installer as this step is failing. If anyone can help reduce the time I would gratefully appreciate the help, but be aware that building locally and building on Github are not the same as the Github environment is a 2xCPU virtual Windows 2019 machine.

So, you mean 3 hours is the time running in your local PC? not the virtual CPU in the Github environment?

[AndrewCot]

But, 3 hrs is too long. 

So, you mean 3 hours is the time running in your local PC? not the virtual CPU in the Github environment?

3hrs on Github.com. You can look at the repo and see it in the actions results.

My local PC the build is about 30 minutes using the same process, which is just okay.

[ollydbg]

OK, so where can I find the generated file? I means the artifact files after running the git action? You can just create a zip file?

[AndrewCot]

As I have said the installer step is not working.

As such there are NO install able/usable artifacts as I use the installer to do updates locally and do NOT have a zip process that zips up the devel31_64 or output31_64 files. You can clone the repo and mod the workflow to zip the devel31_64 directory and upload it so you check it out.
You can look at the actions in the github repo to see the workflow steps being run and the output of them.

[BlueHazzard]

( i have no idea about github actions, so be patient )
Could we possibly use github actions to automate third party plugin building?

[AndrewCot]

Yes, but it may/would/possibly need a bunch of work as it depends on what you exactly want to do.
I have tested parts of the github action workflow by using the nightly zip files to save hours of waiting for wxWidget and C::B to build.

You will need to figure out how you are actually going to build the plugins for the different OS's as the trunk C::B src is not consistent with how it can be built on the different OS's and as such so the plugin build is also not consistent. There are outstanding tickets to do the following for the C::B build prodcess, but they have gone no where. Some of them may be relevant:
1) Add ability to build Windows C::B via the bootstrap/configure/make. This is used in the github actions in my repo.2) Add ability to build MacOS C::B via project files. This is used for MacOS debugging.
3) On MacOS script to install the thirs party build tools and then build WxWidgets and C::B. This is used in the github actions in my repo.4) Updated bootstrap/configure/make process for use on Linux & Windows OS's.  This is used in the github actions in my repo. There are allot of mkaegfile.am changes to get this right.5) Updated src\update*.* files as the build creates the devel31_64 directory structure only and does not do anything with output31_64. The update*.* copies the files from devel to ouput and strips the files. This ensures that the build process builds and the release process takes the build and creates a release.

[ollydbg]

If you look at the page: https://packages.msys2.org/queue

You will see that the wx3.1( wx3.1.6) is ready for upload. That's the work of Tim, see here: wxWidgets3.1: Update to version 3.1.6; and, by stahta01 Pull Request #11691 msys2/MINGW-packages

So, maybe C::B will built against this wx version once it get uploaded?

[AndrewCot]

Thanks, do you know if C::B will work by "just" linking to it? Aka not require you to build wx 3.1.6 from source if you are using it and MSYS2?

The current state as far as I can see is that it has been waiting for 10 days now, so based on what I have seen in the past it is stuck and it will not go anywhere without some help. The MSYS2 pending updates show it as:
 

2022-05-19

mingw-w64-wxWidgets3.1

3.1.5-6

→

3.1.6-1

Ready for upload but waiting for dependencies

[ollydbg]

Thanks, do you know if C::B will work by "just" linking to it? Aka not require you to build wx 3.1.6 from source if you are using it and MSYS2?

If you look at Tim's pull request, you will see that Direct2D is enabled for building C::B, so I guess the answer is Yes. 

The current state as far as I can see is that it has been waiting for 10 days now, so based on what I have seen in the past it is stuck and it will not go anywhere without some help. The MSYS2 pending updates show it as:
 

2022-05-19

mingw-w64-wxWidgets3.1

3.1.5-6

→

3.1.6-1

Ready for upload but waiting for dependencies

I don't know, maybe some MSYS2's developer can help to solve this issue.

[ollydbg]

Well, I saw yesterday, the package information, it shows: Ready for upload.
And now, it shows: Ready for upload but waiting for dependencies.