-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
ExtraDirectory should allow for specifying a target #1581
Comments
Hi @alkoclick, Thanks for the feedback. Adding |
Feature required for my case as well! |
Any update on this @chanseokoh ? My use case for this feature request is that I want to also deploy some libraries and configurations for tomcat when copying the war file but also some scripts. For example:
I can copy them to the base image beforehand but the problem is that I want to be able to update and change them easily instead of recreating the whole base image. I would love to try and create a PR on this if you think this feature is good to have. |
Hi @slowr, We really appreciate external contributions. We do think this feature is very useful and hoped to get to work on this at some point. Sounds like you are serious about creating a PR, so we will have a quick internal design discussion this week to decide how the configuration in Gradle and Maven should look like.
If you haven't noticed, the default "to" directory in the image is always
Note here that the default "from" (
and set |
Thanks a lot for answering!
I know about this solution but the problem is that I have multiple projects that share the same configuration files so I can't actually put these files inside each project. If I am missing something that can make this work for multi-project setup please tell me! |
@slowr someone was having the same problem as yours, and I suggested this workaround. I didn't get a response, so not sure if it worked for them. But I think this will allow you to put the same config files in a single place and share them in a multi-module setup. |
And come to think of it, this issue is about allowing to set the "to" directory, so you will still have the same config-sharing problem even this is fixed. (Just wanted to make sure that you clearly understood what this issue is about.) |
Yes that is true, it didn't click me before! I think getting the work-around and adding files from other projects is doable but having to replicate the absolute path with directories seems to be a bit hacky. |
Anyways, do you still feel like you want to put up a PR? If so, what we decided is extraDirectories.paths = [
{
from: ..., // required
into: ... // "into" is optional and can be omitted ('/' by default)
}, {from: ..., into: ...}, ...
] while at the same retaining the backward-compatibility that the user can continue to do
|
I found a solution to my issue by creating a task that copies everything into a temp directory with the structure you already support and then adding that directory as an tasks.register('jib-directories') {
doLast {
String jibDir = "$project.buildDir/jib-directories", tomcatDir = "/usr/local/tomcat", deployDir = "/usr/local/data"
// copy tomcat files
copy {
from rootProject.files('config/tomcat-modifications/conf')
into "$jibDir/$tomcatDir/conf"
}
// copy deployment files
['bin', 'lib', 'systems', 'xml', 'etc'].each { String dest ->
copy {
from project(':deployment').files("$dest")
into("$jibDir/$deployDir/$dest")
}
}
}
}
jib {
...
extraDirectories.paths = ['.build/jib-directories']
}
tasks.named('jib').configure {
dependsOn jib-directories
} So, do you think this solution is better than introducing |
@slowr thanks for posting the tricks. This will help other users. If you think you are good with your solution and don't have (or just don't want to put any) time on introducing |
if it's not get picked up and I have more time I will take a look and make a PR for this issue so we can have a more clear way to copy files in the container. Thanks a lot for this great project! |
@alkoclick @scripnichenko @slowr @padyx @celcius112 @student-06 @yoshi10321 Jib 2.3.0 is released with this very handy feature. Now you can designate target directories for extraDirectories {
paths {
path {
// copies the contents of 'src/main/extra-dir' into '/' on the container
from = file('src/main/extra-dir')
}
path {
// copies the contents of 'src/main/another/dir' into '/extras' on the container
from = file('src/main/another/dir')
into = '/extras'
}
}
} <configuration>
<!-- Copies files from 'src/main/custom-extra-dir' and '/home/user/jib-extras' instead of 'src/main/jib' -->
<extraDirectories>
<paths>
<!-- Copies from 'src/main/custom-extra-dir' into '/' on the container. -->
<path>src/main/custom-extra-dir</path>
<!-- Copies from '/home/user/jib-extras' into '/extras' on the container -->
<path>
<from>/home/user/jib-extras</from>
<into>/extras</into>
</path>
</paths>
</extraDirectories>
</configuration> |
Description of the issue:
The extraDirectory object is fairly simple to use but imposes an important constraint (mimicking your intended folder structure under the source). This, in turn, makes it essential to use other plugins/functionality to configure the intended directory structure. This code delays execution, introduces duplication (as you will probably already have the desired artifacts, but not in the desired configuration) and blobs the code with what could be a very pretty one-liner.
Expected behavior:
extraDirectories {
paths + targets: ...
permissions: ...
}
Steps to reproduce:
N/A
Environment:
All
Additional Information:
I may be able to help out on this PR?
Thanks for building an awesome tool!
The text was updated successfully, but these errors were encountered: