Skip to content

CI: move docker build machinery to the main repo #2101

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

Merged
merged 1 commit into from
Feb 10, 2025

Conversation

chipitsine
Copy link
Member

@weidi can you please review ?

@chipitsine chipitsine merged commit f525b4d into SoftEtherVPN:master Feb 10, 2025
19 checks passed
@weidi
Copy link
Contributor

weidi commented Feb 10, 2025

Seems i was too slow ;)

I´m thinking of combining all three images into one CI so there lots of time saved in the CI stage.
With the current config each image build is done on a different runner that causes 3 slower runtime.
Another thing that is probably possible to add arm64 (armv7) as platform to the product instead of having it´s own tag -arm64 that is best practice and will make docker-compose configs interoperable between x86 and arm.

{ name: amd64, platform: "linux/amd64", repo: "softethervpn/vpnbridge" },

I will do some tests on that and open MR

Also we should probably archive the -docker repository and bring over the README as README-Docker.md

@chipitsine
Copy link
Member Author

chipitsine commented Feb 10, 2025

Seems i was too slow ;)

I´m thinking of combining all three images into one CI so there lots of time saved in the CI stage. With the current config each image build is done on a different runner that causes 3 slower runtime. Another thing that is probably possible to add arm64 (armv7) as platform to the product instead of having it´s own tag -arm64 that is best practice and will make docker-compose configs interoperable between x86 and arm.

there is always space for improvement.

I decided to mimic current behaviour and not to introduce those improvement on the current stage.
otherwise I would never finish.

{ name: amd64, platform: "linux/amd64", repo: "softethervpn/vpnbridge" },

I will do some tests on that and open MR

there's condition if: ${{ github.repository_owner == 'SoftEtherVPN' }} which prevents those workflows from running in forks. for your experiments you just comment them out in your own fork

Also we should probably archive the -docker repository and bring over the README as README-Docker.md

what I suggest

  1. indeed, docker related documentation might go to the main repo. if you've an appetite for that, please do
  2. I would leave at least stable generating pipeline in dedicated repo.

I like the idea in https://github.com/nginx/nginx-quic-qns where they check commit hash and based on that either build or not. I would implement something like that for stable generation

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

Successfully merging this pull request may close these issues.

2 participants