Findings:
- The command to retrieve digital assets can use an app password provided the target URL is the correct bitbucket REST API endpoint.
- Above must use curl instead of wget. (I could not get wget to work.)
In addition:
- It turns out we can pass the sonatype install4j the install4j properties it needs using bitbucket repository (environment) variables.
The way this works is very simple. This is a feature of maven. If your plugin needs a property defined in the pom.xml as a special tag (e.g., "special.tag"), you can set its content to be $
{some_variable}
. Then, you pass in the value of the variable as an option to maven, like this:
- mvn -Dspecial.tag=$some_variable
You can either pass in the literal value or use an environment variable named "some_variable".
I'm not sure if this works for every possible property/tag. I bet it does, though. I would like to look into it a bit more.
Also, I learned that our install4j configuration file indicated that the location of our jar-signing files was in "/opt/igb", which did not actually exist in our Docker image.
If you don't specify an absolute path, Install4J looks for the indicated key files in "distribution" in the IGB project.
I made changes to pom.xml, bitbucket_pipelines YML, and install4j configuration files to take advantage of above features of maven and pipelines. Changes are merged now into master.
Also, I modified how the pipelines run so that the default pipeline does not try to build installers. This is so that developers that are not building and releasing IGB can still build the project using pipelines. If they do that, what will happen is that an executable jar file containing the IGB version and their bitbucket user name will get build and copied into their fork's download section.
New Feature
Major
Findings:
In addition:
The way this works is very simple. This is a feature of maven. If your plugin needs a property defined in the pom.xml as a special tag (e.g., "special.tag"), you can set its content to be $
{some_variable}. Then, you pass in the value of the variable as an option to maven, like this:
You can either pass in the literal value or use an environment variable named "some_variable".
I'm not sure if this works for every possible property/tag. I bet it does, though. I would like to look into it a bit more.
Also, I learned that our install4j configuration file indicated that the location of our jar-signing files was in "/opt/igb", which did not actually exist in our Docker image.
If you don't specify an absolute path, Install4J looks for the indicated key files in "distribution" in the IGB project.
I made changes to pom.xml, bitbucket_pipelines YML, and install4j configuration files to take advantage of above features of maven and pipelines. Changes are merged now into master.
Also, I modified how the pipelines run so that the default pipeline does not try to build installers. This is so that developers that are not building and releasing IGB can still build the project using pipelines. If they do that, what will happen is that an executable jar file containing the IGB version and their bitbucket user name will get build and copied into their fork's download section.