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

Log Docker Build Context Directory while building image in Simple Dockerfile mode #1192

Conversation

rohanKanojia
Copy link
Member

@rohanKanojia rohanKanojia commented Jan 5, 2022

Description

Add a log statement for Docker Build context directory when building a
docker image in Simple Dockerfile mode.

Related to #1055

Signed-off-by: Rohan Kumar rohaan@redhat.com

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • Feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change
  • Chore (non-breaking change which doesn't affect codebase;
    test, version modification, documentation, etc.)

Checklist

@codecov
Copy link

codecov bot commented Jan 5, 2022

Codecov Report

Merging #1192 (262b449) into master (fd859ce) will increase coverage by 0.00%.
The diff coverage is 53.84%.

Impacted file tree graph

@@            Coverage Diff            @@
##             master    #1192   +/-   ##
=========================================
  Coverage     50.15%   50.16%           
- Complexity     3698     3699    +1     
=========================================
  Files           457      457           
  Lines         20605    20607    +2     
  Branches       2805     2805           
=========================================
+ Hits          10334    10337    +3     
+ Misses         9187     9185    -2     
- Partials       1084     1085    +1     
Impacted Files Coverage Δ
...be/maven/plugin/mojo/build/AbstractDockerMojo.java 18.62% <0.00%> (ø)
...se/jkube/maven/plugin/mojo/build/ResourceMojo.java 0.00% <0.00%> (ø)
...se/jkube/gradle/plugin/task/AbstractJKubeTask.java 88.75% <100.00%> (+0.14%) ⬆️
.../kit/build/service/docker/helper/ConfigHelper.java 57.69% <100.00%> (+0.54%) ⬆️
...it/config/service/portforward/PortForwardTask.java 64.00% <0.00%> (+4.00%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fd859ce...262b449. Read the comment docs.

@rohanKanojia rohanKanojia marked this pull request as ready for review January 10, 2022 06:39
@@ -181,7 +182,7 @@ private static void verifyImageNames(List<ImageConfiguration> ret) {
}
}

public static List<ImageConfiguration> initImageConfiguration(String apiVersion, Date buildTimeStamp, JavaProject javaProject, List<ImageConfiguration> images, ImageConfigResolver imageConfigResolver, KitLogger log, String filter, ConfigHelper.Customizer customizer) {
public static List<ImageConfiguration> initImageConfiguration(String apiVersion, Date buildTimeStamp, JavaProject javaProject, List<ImageConfiguration> images, ImageConfigResolver imageConfigResolver, KitLogger log, String filter, ConfigHelper.Customizer customizer, JKubeConfiguration jKubeConfiguration) {
Copy link
Member

Choose a reason for hiding this comment

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

Haven't checked the rest, but JKubeConfiguration should already contain the JavaProject instance (So replacing one with the other should do in this case).

@@ -211,6 +212,7 @@ private static void verifyImageNames(List<ImageConfiguration> ret) {
BuildConfiguration buildConfiguration = image.getBuildConfiguration();
if (buildConfiguration != null && buildConfiguration.isDockerFileMode()) {
log.info("Using Dockerfile: %s", buildConfiguration.getDockerFile().getAbsolutePath());
log.info("Using Docker Context Directory: %s", buildConfiguration.getAbsoluteContextDirPath(jKubeConfiguration.getSourceDirectory(), jKubeConfiguration.getBasedir().getAbsolutePath()));
Copy link
Member

Choose a reason for hiding this comment

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

Aren't these directories in JavaProject?

I remember in the early days these fields were scattered all around and we managed to reduce them to just the JKubeConfiguration and the JavaProject instances.
What's the issue in this case?

Copy link
Member

Choose a reason for hiding this comment

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

If the homonymous fields have the same purpose, one set should be deprecated. If not, the undocumented, should be. This way we would avoid situations like the current were there's confusion about what should be used

Copy link
Member Author

Choose a reason for hiding this comment

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

I can see jKubeConfiguration.getBaseDir() returns JavaProject's base directory. But I'm not able to find any sourceDirectory equivalent in JavaProject

Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
log.info("Using Docker Context Directory: %s", buildConfiguration.getAbsoluteContextDirPath(jKubeConfiguration.getSourceDirectory(), jKubeConfiguration.getBasedir().getAbsolutePath()));
log.info("Using Docker context directory: %s", buildConfiguration.getAbsoluteContextDirPath(jKubeConfiguration.getSourceDirectory(), jKubeConfiguration.getBasedir().getAbsolutePath()));

Copy link
Member

Choose a reason for hiding this comment

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

I can see jKubeConfiguration.getBaseDir() returns JavaProject's base directory. But I'm not able to find any sourceDirectory equivalent in JavaProject

OK, so this one is not duplicate, it just retrieves javaProject.baseDirectory

However, outputDirectory is still defined in both places. We'll need to investigate and deprecate, rename or proper document them.

@rohanKanojia rohanKanojia force-pushed the pr/log-contextdir-simpledockerfilemode branch 2 times, most recently from 929fb20 to 91e7aa7 Compare January 11, 2022 17:11

public class ConfigHelperTest {
@Mocked
Copy link
Member

Choose a reason for hiding this comment

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

Why not using Mockito annotations ?

Copy link
Member

Choose a reason for hiding this comment

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

You'd need to run the test with MockitoJUnitRunner.class

These annotations were the ones provided by JMockit.

private ImageConfigResolver mockedImageConfigResolver;

private OpenshiftResourceMojo openShiftResourceMojo;

@Before
public void setUp() throws IOException {
public void setUp() {
mockedClusterAccess = mock(ClusterAccess.class, RETURNS_DEEP_STUBS);
Copy link
Member

@sunix sunix Jan 13, 2022

Choose a reason for hiding this comment

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

I feel like there are too many nested mocks here which may not be needed if you use RETURNS_DEEP_STUBS and or @InjectMocks. It makes this part hard to read (and maintain).

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks, you're right. I was able to remove unnecessary mocks for JKubeConfiguration class by using RETURNS_DEEP_STUBS

@Before
public void setUp() {
imageConfigResolver = mock(ImageConfigResolver.class, RETURNS_DEEP_STUBS);
logger = mock(KitLogger.class, RETURNS_DEEP_STUBS);
Copy link
Member

Choose a reason for hiding this comment

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

If we are not verifying any of the logged messages, SilentLogger is a good option for tests instead of using a mock.

Copy link
Member Author

Choose a reason for hiding this comment

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

Do you have some examples of using it? I'm not able to find any references to SilentLogger in this repository

@rohanKanojia rohanKanojia force-pushed the pr/log-contextdir-simpledockerfilemode branch 2 times, most recently from b52c43d to d40505e Compare January 20, 2022 07:01
@Before
public void setUp() {
imageConfigResolver = mock(ImageConfigResolver.class, RETURNS_DEEP_STUBS);
logger = mock(KitLogger.SilentLogger.class, RETURNS_DEEP_STUBS);
Copy link
Member

Choose a reason for hiding this comment

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

#1192 (comment)

The idea is not to mock the logger unless we need to verify something.

Suggested change
logger = mock(KitLogger.SilentLogger.class, RETURNS_DEEP_STUBS);
logger = new KitLogger.SilentLogger();

@rohanKanojia rohanKanojia force-pushed the pr/log-contextdir-simpledockerfilemode branch from d40505e to 0509f31 Compare January 25, 2022 16:06
@manusa manusa added this to the 1.6.0 milestone Jan 31, 2022
…kerfile mode

Add a log statement for Docker Build context directory when building a
docker image in Simple Dockerfile mode.

Related to eclipse-jkube#1055

Signed-off-by: Rohan Kumar <rohaan@redhat.com>
@rohanKanojia rohanKanojia force-pushed the pr/log-contextdir-simpledockerfilemode branch from 0509f31 to 262b449 Compare January 31, 2022 09:57
@sonarcloud
Copy link

sonarcloud bot commented Jan 31, 2022

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

14.3% 14.3% Coverage
0.0% 0.0% Duplication

@manusa manusa merged commit dd26a36 into eclipse-jkube:master Jan 31, 2022
@rohanKanojia rohanKanojia deleted the pr/log-contextdir-simpledockerfilemode branch January 31, 2022 13:21
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.

None yet

3 participants