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

Release/1.4.0 alpha2 #226

Merged
merged 6 commits into from
Mar 2, 2022
Merged

Release/1.4.0 alpha2 #226

merged 6 commits into from
Mar 2, 2022

Conversation

remcowesterhoud
Copy link
Contributor

@remcowesterhoud remcowesterhoud commented Mar 2, 2022

Description

Several fixes in the workflow to deal with the fact that git is in headless mode when checking out a release tag.

  1. The deploy to maven and the deploy to docker jobs have been combined into a single deploy job
  2. Maven is now used to set the image tag in extension-testcontainer config file.
  3. A new step had been introduces to make sure changes on the main branch are still using the latest tag. This way we keep the same behaviour as we had previously.

Definition of Done

Not all items need to be done depending on the issue and the pull request.

Code changes:

  • The changes are backwards compatibility with previous versions
  • If it fixes a bug then PRs are created to backport the fix

Testing:

  • There are unit/integration tests that verify all acceptance criterias of the issue
  • New tests are written to ensure backwards compatibility with further versions
  • The behavior is tested manually

Documentation:

  • Javadoc has been written
  • The documentation is updated

@remcowesterhoud
Copy link
Contributor Author

@pihme I've fixed the workflow. I think this covers all cases.

  1. Commits on main will create an image with the latest tag. SNAPSHOT releases will have latest in the config. The Update tag in config step which is only run on the main branch will make sure maven doesn't override the tag in the config with the ${project.version}.
  2. All releases will create an image with the tag set to the released version. Maven will take care of this version in the config by overriding the ${project.version}.

@remcowesterhoud remcowesterhoud requested a review from pihme March 2, 2022 10:36
Copy link
Contributor

@pihme pihme left a comment

Choose a reason for hiding this comment

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

Looks good to me.

The only concern I have that in two months we will have forgotten how it works exactly. Maybe you could add some comments or documentation to explain the solution

@github-actions
Copy link

github-actions bot commented Mar 2, 2022

Unit Test Results

124 files  124 suites   5m 50s ⏱️
321 tests 321 ✔️ 0 💤 0
772 runs  772 ✔️ 0 💤 0

Results for commit bb05eb9.

♻️ This comment has been updated with latest results.

In the "Update image and tag in Git" step we update the configuration file with the proper image name and tag. For workflows triggered by releases this part is done in HEADLESS mode. This means we cannot push these changes to a remote.

In the deploy-to-maven job we did a new checkout of the code. In this code the changes we made in te "Update image and tag in Git" are not available. This causes the application to be packaged whilst pointing to the wrong image.

By combining these 2 jobs into one we no longer do a 2nd checkout. As a result the application gets packaged with the correct configurations.
Adding this as a resources to maven and applying filtering allows maven to set the tag dynamically to the project.version.

When we create a new release we will build a new image tagged with the release version. Maven will build the application with the release version. By syncing these 2 up the version should always match.
Maven overrides the image tag in the config with the project.version. This works fine for releases. Release X.Y.Z gets created, an image is built and pushed with tag X.Y.Z and maven updates the config to X.Y.Z and packages the application.

The main branch is an exception here. The project.version in this case would be X.Y.Z-SNAPSHOT. We don't want to publish a lot of different SNAPSHOT versions on docker hub. For this reason we should override it with latest. The workflow would then be as follows:

1. A change is pushed to the main branch
2. Everything gets tested and verified
3. A docker image is built and pushed with the tag "latest"
4. We update the configuration to set the tag to "latest"
5. Maven doesn't replace any of configuration and packages it using "latest".

If we don't add this step maven will replace the tag in the config to X.Y.Z-SNAPSHOT. This does not match the tag of the image we just built.
There is some logic and exceptions in surrounding the image tag. These comments aim to explain why these steps are required and why they do what they do.
remcowesterhoud and others added 2 commits March 2, 2022 14:42
Automatic code formatting is causing more issues than it's worth at this moment. Instead we should fail the build if the checks don't pass and fix the issue manually.
@remcowesterhoud remcowesterhoud merged commit f01cccf into main Mar 2, 2022
@remcowesterhoud remcowesterhoud deleted the release/1.4.0-alpha2 branch March 2, 2022 15:18
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