Download sealights agent from 'customAgentUrl'

[ursulaflorianczyk]

Download sealights agent from 'customAgentUrl'

Some our customers want to have possibility to download specific Sealights agent from their internal URL instead of public Sealights servers. We want to provide them the easy way to configure it by adding a new parameter 'customAgentUrl'. Sealights buildpacks should support the same parameter for the same template across all technologies that is why we add 'customAgentUrl' instead of 'custom_agent_url'.

• We read the value of new parameter both from app configuration and sealights user-provided service
• Searching for jar which name starts with 'sl-test-listener' in zip downloaded from customAgentUrl
• Set system property sl.enableUpgrade to false when agent is downloaded from customAgentUrl (this is a functional requirement to block our agent from auto-upgrading)

This PR contains also:

• 'enable_upgrade'/'auto_upgrade' parameter name fix in sealights_agent.yml config yml file. We had the names mismatch. We had defined 'auto_upgrade' parameter In sealights_agent.yml config file, but in buildpack code we checked if 'enable_upgrade' is set in app configuration. The value of 'auto_upgrade' was never checked in sealights framework code. I removed 'auto_upgrade' in sealights_agent.yml and added definition for 'enable_upgrade'.
• Modified adding system property 'sl.tag' to contain buildpack version

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: ursulaflorianczyk (1a3aa19befe08dfa52d1bf528f3e1bfec1e86868)

[ursulaflorianczyk]

@pivotal-david-osullivan can I ask you for review and merging this PR?

[ursulaflorianczyk]

Hello Java Buildpack Team. We would like to merge this PR to Sealights' buildpack. Could you please give me a suggestion what I should do to get review/approval and merging for this PR? @pivotal-david-osullivan @rhardt-pivotal do you know who I should contact?

[anthonydahanne]

Hello! Sorry for the long time to get back to you - thanks for your contribution. I have to ask you: why didn't you use the "standard" java buildpack way of getting dependencies.

In the case of sealights agent, if you look at the default configuration, you'll guess that the dependency is fetched from the latest in https://agents.sealights.co/pcf/index.yml

So if you rebuilt the java-buildpack changing

repository_root: https://agents.sealights.co/pcf

to

repository_root: https://my-own-bucket.com

and then published at https://my-own-bucket.com/index.yml a file with your own packaging of sealights, you'd be done.

Please let me know why you decided to divert from this way of providing different dependencies. Thank you!

[ursulaflorianczyk]

Hi @anthonydahanne Thank you for your feedback! One of our customers want to use Sealights agent downloaded from his internal URL. We would like to avoid asking him to rebuilt buildpack and providing his own /index.yml (https://his-own-bucket.com/index.yml).

[pivotal-david-osullivan]

Anthony is correct, you must host the index.yml file with the <version>: <dep_uri> syntax. However, you do not need to repackage/rebuild the buildpack. You can set the operator or developer level environment variable to use the custom repository root where the new index is hosted, e.g.

JBP_CONFIG_SEALIGHTS_AGENT '{ repository_root: "<uri>" }'