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

Check if bootWar/war tasks are enabled #2096

Closed
mattysweeps opened this issue Oct 24, 2019 · 9 comments · Fixed by #2107
Closed

Check if bootWar/war tasks are enabled #2096

mattysweeps opened this issue Oct 24, 2019 · 9 comments · Fixed by #2107
Milestone

Comments

@mattysweeps
Copy link

mattysweeps commented Oct 24, 2019

Environment:

  • Jib version: 1.7.0
  • Build tool: gradle 5.2.1
  • OS: linux

Description of the issue:
When a project enables the war task but disables the bootWar task, Jib incorrectly chooses the bootWar task to depend on, instead of the war task.

Expected behavior:
Jib should depend on enabled tasks only.

Steps to reproduce:

  1. apply plugins 'org.springframework.boot' and jib
  2. set bootWar { enabled = false } and war { enabled = true } in build.gradle
  3. gradle jib

Log output:

Additional Information:

TaskProvider<Task> warTask = TaskCommon.getWarTaskProvider(project);

@loosebazooka
Copy link
Member

This seems like the right thing to do, but out of curiosity: why are you disabling the bootwar task?

@mattysweeps
Copy link
Author

mattysweeps commented Oct 24, 2019

@loosebazooka The project I'm trying to use with Jib is https:/cloudfoundry/uaa, specifically the ./uaa/build.gradle https:/cloudfoundry/uaa/blob/develop/uaa/build.gradle

I'm not sure why bootWar is disabled, but I believe it's because the app is transitioning to a spring boot app from a spring XML one.

Here's my PR for the changes I made cloudfoundry/uaa#1129

@chanseokoh
Copy link
Member

Hey @slowr, asking for help, since you've recently modified our code to use TaskProvider. It seems like in order to determine if the bootWar task is enabled, I need to retrieve it first (i.e., .get().getEnabled()). And then Jib should dynamically determine whether it should depend on the war task or the bootWar task. But calling TaskProvider.get() defeats #2072. What should be the best way?

@slowr
Copy link
Contributor

slowr commented Oct 26, 2019

I don't think it is possible to get the enabled state without creating the task. I asked the Gradle community and this was the answer I got back:

probably not, because enable/disable can be  written to by configuration actions 
attached to the provider, so you wouldn't get the right answer. in fact, I think all 
tasks would report enabled = true

@loosebazooka
Copy link
Member

Can we depend on both as task dependencies and query the correct config data later?

@chanseokoh
Copy link
Member

Ah, yeah, haven't thought about it. I think it can be the best compromise. That is, we configure Jib runs to depend on both war and bootWar tasks if they are available.

@chanseokoh
Copy link
Member

@mattysweeps I realized the reproducible steps you wrote aren't really correct, so let me check if we are on the same page.

  1. apply plugins 'org.springframework.boot' and jib
  2. set bootWar { enabled = false } in build.gradle
  3. gradle jib

AFAIK, when you apply 'org.springframework.boot' to a WAR project (i.e., a project where the War plugin is applied), it automatically creates the bootWar task and disables the war task. This is documented, and from my experiment this seems true. Then, if you just disable bootWar, both war and bootWar are disabled and no WAR file is ever produced. So, there should be an additional step to set war { enabled = true }. Did I miss something?

@mattysweeps
Copy link
Author

@chanseokoh Ah, I see. I believe you are correct. That's what I see in the build.gradle file I'm using:
https:/cloudfoundry/uaa/blob/develop/uaa/build.gradle#L16

I'll update the issue description

@chanseokoh
Copy link
Member

@mattysweeps we just released 1.8.0 with the fix.

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 a pull request may close this issue.

4 participants