Update gradle extraDirectory config parameter to include path and permissions field

[TadCordle]

Toward #794

extraDirectory configuration parameter is now an object with a path and permissions field, instead of just being a file

• extraDirectory.path covers the original purpose of extraDirectory
• extraDirectory.permissions is a map from path on container to an octal string representation of the file's permission bits

For example, if your extra directory is (project dir)/src/main/custom-jib, and you want to give executable permissions to path/to/file1 and path/to/file2 within, you would add this configuration to your build.gradle:

jib {
  ...
  extraDirectory {
    path = file('src/main/custom-jib')
    permissions = [
      '/path/to/file1': '755',
      '/path/to/file2': '755'
    ]
  }
}

The old method of configuring the extra directory is also still supported:

jib {
  ...
  extraDirectory = file('src/main/custom-jib')
}

[chanseokoh]

I wonder how this will look like in Maven, because currently for other maps, an HTML tag name works as a key to the maps. But obviously we can't do </path/to/file2>777<//path/to/file2>.

Assuming that this will break the existing users who configured extraDirectory, another thing I'd like to make sure is that existing users will get a good error message so that they have no friction in updating their config, not like a native Java type mismatch error or such.

[TadCordle]

I wonder how this will look like in Maven, because currently for other maps, an HTML tag name works as a key to the maps. But obviously we can't do </path/to/file2>777<//path/to/file2>.

Judging by the original comment, I think we can make the map an alternating list style sort of thing:

<extraDirectory>
  <path>extra/dir/path</path>
  <permissions>
    <file>/path/file1</file>
    <mode>755</mode>
    <file>/path/file2</file>
    <mode>755</mode>
  </permissions>
</extraDirectory>

Assuming that this will break the existing users who configured extraDirectory, another thing I'd like to make sure is that existing users will get a good error message so that they have no friction in updating their config, not like a native Java type mismatch error or such.

Yeah, I think I would have liked to deprecate the parameter first, but considering we're keeping the parameter and just changing its type I wasn't sure how the best way to do this.

[coollog]

A slight correction on the Maven config, but otherwise looks good:

<extraDirectory>
  <path>extra/dir/path</path>
  <permissions>
    <permission>
      <file>/path/file1</file>
      <mode>755</mode>
    </permission>
    <permission>
      <file>/path/file2</file>
      <mode>755</mode>
    </permission>
  </permissions>
</extraDirectory>

I think for Gradle, we could actually support both the use of extraDirectory as a closure with the path and permissions fields or as a file to just be the path.
I believe in Maven, there's some way to make it so that if the user just uses <extraDirectory>some/path</extraDirectory>, it can take some/path as the path nested input, but I'll need to find that again.

[TadCordle]

Hmmm I just noticed that changing permissions in the build file without changing anything in the extra directory itself causes the extra layer to not be updated because file permissions aren't cached.

Edit: still works with ./gradlew clean, so maybe I should just make an issue and fix it in another PR.

[TadCordle]

Have updated to support both jib.extraDirectory { ... } and jib.extraDirectory = file(...).

[coollog]

Good catch, we'll need to update the selector to include permissions then.

[coollog]

LGTM, will have someone else do the final approval.

[chanseokoh]

LGTM. I'll just do an actual test real quick.

[chanseokoh]

Let's mention that the input map is a file-path-to-file-permission map. Without any context, it's not clear what the map is about.

[chanseokoh]

Let's mention this applies only to the files from extraDirectory.