EVA-4114 - Automated deployment#98
Conversation
| - tags | ||
|
|
||
| # ============================================================================ | ||
| # DEVELOPMENT: Deploy on main branch (manual trigger) |
There was a problem hiding this comment.
What's the reasoning behind making the dev deploys manual, but the prod ones automatic?
There was a problem hiding this comment.
The initial rational was to allow more deployments on dev prior to merging while not deploying for every push. However After looking into it I realised that I could not deploy any code from forks because they are not mirrored. I'll remove the manual trigger.
| @@ -1,30 +1,31 @@ | |||
|
|
|||
| spring.profiles.active=@spring.profiles.active@ | |||
There was a problem hiding this comment.
Is there a way to use a single environment variable to select the profile within settings.xml (pulled from the configuration repo), and use that to set the relevant properties? I see Spring uses a SPRING_PROFILES_ACTIVE env variable, presumably it could be hooked into the Gitlab/K8s deployment similar to the other variables.
The approach here is probably fine, I'm just not sure I like the idea of storing so many properties in the Gitlab CI, it seems less legible and harder to maintain.
There was a problem hiding this comment.
I agree that this is not optimal and that the number of env variable in Gitlab will quickly get out of hands
The main problem with the maven file + profile is that this is not supported by k8s deployment. We could still make it work:
- as you said we could download the maven file at run time and apply it with a profile provided as an environment variable
- we could also provide the maven file as an environment variable blob and write it to file before starting java
These solution would apply to any java web service but not to non java ones.
I think the reason k8s is using environment variable is because it is almost always available as a way of injecting parameters.
We could also look into how we can manage env variable outside of gitlab variables
This sounds like a longer conversation is needed.
|
I'll merge for now to be able to test in Gitlab |
Automated deployment with Gitlab
Change the build to use Jar and take the parameters at run time
Adapted the tests