Skip to content

EVA-4114 - Automated deployment#98

Merged
tcezard merged 8 commits into
EBIvariation:mainfrom
tcezard:Automated_deployment
Jun 24, 2026
Merged

EVA-4114 - Automated deployment#98
tcezard merged 8 commits into
EBIvariation:mainfrom
tcezard:Automated_deployment

Conversation

@tcezard

@tcezard tcezard commented Jun 17, 2026

Copy link
Copy Markdown
Member

Automated deployment with Gitlab
Change the build to use Jar and take the parameters at run time
Adapted the tests

@tcezard tcezard changed the title Automated deployment EVA-4114 - Automated deployment Jun 17, 2026
Comment thread .github/workflows/maven.yml Outdated
Comment thread pom.xml Outdated
Comment thread .github/workflows/maven.yml Outdated
Comment thread .gitlab-ci.yml
- tags

# ============================================================================
# DEVELOPMENT: Deploy on main branch (manual trigger)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reasoning behind making the dev deploys manual, but the prod ones automatic?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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@

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@tcezard

tcezard commented Jun 24, 2026

Copy link
Copy Markdown
Member Author

I'll merge for now to be able to test in Gitlab

@tcezard tcezard merged commit 6f97933 into EBIvariation:main Jun 24, 2026
2 checks passed
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.

3 participants