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

[build][CI/CD] enable each time push will generate a new page to test #3

Open
eat4toast opened this issue Oct 3, 2022 · 0 comments

Comments

@eat4toast
Copy link

eat4toast commented Oct 3, 2022

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

  1. we build whole docker images each time if push/pr or another event is to be triggered.
  2. 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 pull gnuradio, 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.

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

1 participant