-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
[docker] build files for automated builds #836
Conversation
@wing328 @jmini if this gets merged into master, I can setup automated builds using patterns for branches, tags, and master. I could also look at configuring https://hub.docker.com/r/openapitools/openapi-generator-cli and https://hub.docker.com/r/openapitools/openapi-generator-online to work as triggered builds for releases as well. |
Could the 2 files be under the If I understood this correctly, if we use "Docker Hub for automated builds" we will no longer push images from "travis". Should we disable docker-push from travis within the same PR? Otherwise how will we be able to see if your setup of "Docker Hub for automated builds", if we have travis also pushing images? For me the appropriate moment to do the switch would be right after the next release |
If we put it under CI, it complicates the context because Docker hub doesn't allow you to define the build context path. I'd rather keep these as hidden files in the root. Once this is in master, we can merge to the versioned branches and evaluate. There's no need to remove the Travis step until the automated build stuff is working as expected. We'll need to figure out how we'd want to deprecate the other two Docker repos, are if there's a way to trigger a build of those based on the automated build. The latter might be confusing. |
* master: Fix problems in typescript jquery generator (#801) [PHP] Add gitignore to AbstractPhpCodegen (#765) Improve documentation for usage of a generator in an other jar (#817) Improve Symfony 4.1 compatibility (#830) 📝 Updating 'help generate' switches in README [cli] Don't log to STDOUT if debug flags are set (#474) [gradle-plugin] README notes on multiple specs (#847) Added server variable support (#816) fix erlang optiona/required parameters (#829) [Java][Rest-assured] Fix generated javadoc and "swagger-annotations" improvement (#831)
d051140
to
5e44a83
Compare
@jmini in case you're not familiar with the aspect of Docker… if you move the files under
I think having the files as hidden files in the root for the benefit of having an automated build is a fair trade-off. |
For this case, I think it's totally ok to leave the files in the root directory instead of putting them under the |
I was just asking a question, not requesting a change... If you are sure that this change do not break the release we will perform tomorrow and that "docker push from travis" can still be used in parallel to this automated docker build (which seems to be the case), this PR is harmless. |
@jmini yeah it doesn't affect the Dockerfile in either of the published images. I left those as-is because people use them for local development and that use case wouldn't work well with a jar-only image. |
@jimschubert thanks for the enhancement. Let's move forward with the change. |
PR checklist
./bin/
to update Petstore sample so that CIs can verify the change. (For instance, only need to run./bin/{LANG}-petstore.sh
and./bin/security/{LANG}-petstore.sh
if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in.\bin\windows\
.master
,3.3.x
,4.0.x
. Default:master
.Description of the PR
Creates multi-stage docker files for use on Docker Hub for automated builds at https://hub.docker.com/r/openapitools/openapi-generator.