Publish the bootloader JAR

[davinchia]

What

Publish the Bootloader Jar so code can be consumed and extended in Cloud.

Today we mostly do so via bundling this with the Server app. I decided against this for the bootloader since the Server does not have to interact with the Bootloader, so there is no reason to further mess up the dependencies. It is cleaner to add a separate publishing section to the Bootloader gradle file.

Consumed in https://github.com/airbytehq/airbyte-cloud/pull/732.

How

See the What section.

Recommended reading order

1. bootloader/build.gradle

🚨 User Impact 🚨

Are there any breaking changes? What is the end result perceived by the user? If yes, please merge this PR with the 🚨🚨 emoji so changelog authors can further highlight this if needed.

Pre-merge Checklist

Expand the relevant checklist and delete the others.

New Connector

Community member or Airbyter

• Community member? Grant edit access to maintainers (instructions)
• Secrets in the connector's spec are annotated with airbyte_secret
• Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
• Code reviews completed
• Documentation updated
  • Connector's README.md
  • Connector's bootstrap.md. See description and examples
  • docs/SUMMARY.md
  • docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
  • docs/integrations/README.md
  • airbyte-integrations/builds.md
• PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

• Create a non-forked branch based on this PR and test the below items on it
• Build is successful
• Credentials added to Github CI. Instructions.
• /test connector=connectors/<name> command is passing.
• New Connector version released on Dockerhub by running the /publish command described here
• After the connector is published, connector added to connector index as described here
• Seed specs have been re-generated by building the platform and committing the changes to the seed spec files, as described here

Updating a connector

Community member or Airbyter

• Grant edit access to maintainers (instructions)
• Secrets in the connector's spec are annotated with airbyte_secret
• Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
• Code reviews completed
• Documentation updated
  • Connector's README.md
  • Connector's bootstrap.md. See description and examples
  • Changelog updated in docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
• PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

• Create a non-forked branch based on this PR and test the below items on it
• Build is successful
• Credentials added to Github CI. Instructions.
• /test connector=connectors/<name> command is passing.
• New Connector version released on Dockerhub by running the /publish command described here
• After the new connector version is published, connector version bumped in the seed directory as described here
• Seed specs have been re-generated by building the platform and committing the changes to the seed spec files, as described here

Connector Generator

• Issue acceptance criteria met
• PR name follows PR naming conventions
• If adding a new generator, add it to the list of scaffold modules being tested
• The generator test modules (all connectors with -scaffold in their name) have been updated with the latest scaffold by running ./gradlew :airbyte-integrations:connector-templates:generator:testScaffoldTemplates then checking in your changes
• Documentation which references the generator is updated as needed.

[davinchia]

Tested this by running ./gradlew publish locally.

[jrhizor]

Is there something we can do to make https://github.com/airbytehq/airbyte-cloud/wiki/Developing-Against-OSS-Jars easier if we're starting to publish more jars for Cloud? Maybe we can share the shadowJar and publishing logic across multiple containers and inject an override version in a more standard way?

Otherwise it seems like it'd be operationally easier to just put this in the same server jar until we do this correctly across the board.

Marking as approve since I don't want to block you on this either way.

[davinchia]

Otherwise it seems like it'd be operationally easier to just put this in the same server jar until we do this correctly across the board.

Had the same thought here. I ended up not doing this since it would increase the server jar size. What we currently do with the server is 'okay' since everything is consumed by the server. The bootloader isn't, so putting it there seeemed icky to me.

Maybe we can share the shadowJar and publishing logic across multiple containers and inject an override version in a more standard way?

Agree we should do this. Happy to brainstorm more ideas. Maybe during our mini hackweek.