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
I wonder if there are some ways to do unit/smoke tests, seems it's hard to do this.
And we need to deploy a new page through GitHub Action to display the result in each push/pull request event to be triggered (work as CI/CD) which will enable more people to join this project.
Also, referring to this, there are 2 major ways to build gr-web in GitHub Action
we build whole docker images each time if push/pr or another event is to be triggered.
we are using different jobs to specify which image should be rebuilt, well the other will be stored in the docker hub which will save huge time.
I intend to work the last way. Which need to support 2 things, one for display pages (just pull from docker hub), another for modifying docker in docker hub (if community someone modifies the docker file with a feature enhancement )
edit2:
Back to the last way, there 2 deeper thinking based on which image we place in the docker hub:
2.1 We only push gnuradio this image to the docker hub
2.2 We push the different images to docker hub (like volk, CPython, pyqt, boost, etc), this way maybe more save time but will suffer an interesting consistency problem(more in below hide HTML) and can be handled with "each time we modify the base image, we need re-compile and push to docker hub the high-level image's latest version." which result actually the saved time it depends on the re-compile time. Here is a reference about using cache to accelerate CI workflow.
interesting build problem
premise:
And for some python script modifications, we only need to pull the gnuradio image to generate the newer version js data.
Obviously, there exist topological order between different docker build base container. For example: if we wanna build volk, we need to get CPython first.
traditional case:
Consider there are 2 pr that will need to run GitHub action (one will modify CPython.dockerfile to generate debug version CPython, and another one will modify the flowgraph.py)
for the first one, the GitHub actions have concerned this push/pr will modify the CPython this image, it will rebuild the image and push to hub docker.
for the second one: the GitHub action just need to pullgnuradio, and it will pull from the docker hub to get the latest image. it's unaware for the gnuradio image actually needs re-compile with a debug version CPython image.
conclusion
So each image to be modified and then the other later/over this layout image should also be re-compiled and pushed to docker hub. Here are exist other ways to cache or accelerate in the newer image building.
The text was updated successfully, but these errors were encountered:
I wonder if there are some ways to do unit/smoke tests, seems it's hard to do this.
And we need to deploy a new page through GitHub Action to display the result in each push/pull request event to be triggered (work as CI/CD) which will enable more people to join this project.
Also, referring to this, there are 2 major ways to build gr-web in GitHub Action
I intend to work the last way. Which need to support 2 things, one for display pages (just pull from docker hub), another for modifying docker in docker hub (if community someone modifies the docker file with a feature enhancement )
edit2:
Back to the last way, there 2 deeper thinking based on which image we place in the docker hub:
gnuradiothis image to the docker hubinteresting build problem
premise:
And for some python script modifications, we only need to pull the
gnuradioimage to generate the newer version js data.Obviously, there exist topological order between different docker build base container. For example: if we wanna build
volk, we need to getCPythonfirst.traditional case:
Consider there are 2 pr that will need to run GitHub action (one will modify
CPython.dockerfileto generate debug version CPython, and another one will modify theflowgraph.py)for the first one, the GitHub actions have concerned this push/pr will modify the
CPythonthis image, it will rebuild the image and push to hub docker.for the second one: the GitHub action just need to pull
gnuradio, and it will pull from the docker hub to get the latest image. it's unaware for thegnuradioimage actually needs re-compile with a debug versionCPythonimage.conclusion
So each image to be modified and then the other later/over this layout image should also be re-compiled and pushed to docker hub. Here are exist other ways to cache or accelerate in the newer image building.
The text was updated successfully, but these errors were encountered: