created a new repo for the app which can be found at:
https://bitbucket.org/pkulka10/transcriptisoform/src/master/
Please let me know if you want me to transfer the ownership of the repository to lorainelab.

Commits are visible from way back. Do please go ahead and transfer the repo to lorainelab.

I have transferred the ownership to lorainelab now.

Repository transfer is accepted.
Moving back to "to do" and assigning to myself as a reminder to set up bitbucket pipelines for this new repo.

There is no pipeline file in the repo. This needs to be added.

To do this:

• Copy NCBI primer App bitbucket pipelines file and update it for the new App
• Check that we are using the latest Docker image by looking at the bitbucket pipelines file for the IGB repository.

The repository for Transcript Isoform is https://bitbucket.org/lorainelab/transcriptisoform.
The repository for NCBI Primer App is https://bitbucket.org/lorainelab/ncbi-primer

Recommended workflow:

• Fork Transcript Isoform App.
• Enable bitbucket piplines on your new fork.
• Create a bitbucket.yml file in your fork.
• Copy the text from NCBI Primer App Bitbucket pipeline into that file.
• Edit it (replace NCBI primer app reference with "transcript isoform")
• Add a BB_AUTH_STRING as a new repository variable in your fork.
• Run the pipeline manually to test.

Link to branch: https://bitbucket.org/Rweidenh/transcriptisoform/branch/IGBF-2373

The pipelines file is added and
the Docker image is updated to jre-1.8.0_241

mvn clean package error
It appears that the POM needs to be reconfigured.

Please re-read:

https://canvas.instructure.com/courses/1164217/pages/understand-igb-development-workflow?module_item_id=12709540

Once the installer is built, developer adds a link to their topic branch to the Jira issue as a Comment. They then move the issue into the next column - "Needs 1st Level Review" - and un-assigns the issue. This signals to everyone else that the issue is now ready for review, and anyone with time and expertise can pick it up.

When you move to "Needs 1st Level Review" you need to un-assign the issue so that everyone knows it's ready to be picked up and reviewed. If you leave it assigned to yourself, everyone else will think you are planning to review it. They won't see that you were the original developer unless they click on it and read it.

cc: Jay Chamma

Change requests:

• Edit the commit message to include the ticket name (see examples from commit history)

Also, to make working with the fork more convenient

• Add a Jira link to your transcript isoform fork - see new page in Canvas course with info on how to do this

I realized when I looked at your fork that I failed to include the Jira link configuration step.

I fixed this just now by adding a new page and reorganizing an existing page.

Please go back to the IGB class Module titled "Setting up" and read the content again.

Then try to add the Jira link to your IGB fork and to your fork of the Transcript Isoform repository. Add any comments you have here for me to take a look.

I would like to improve the on-boarding materials so your feedback could be super helpful!

cc: Logan Weidenhammer

Commit message is edited to include the ticket name IGBF-2373 with a short description.

The Jira link is added to my Transcript Isoform fork per the canvas instructions.

Canvas page feedback:

Under "Set up your local IGB development environment" > "Clone your fork to your local computer" > "3. Install the version of Java needed by IGB".
The link for number 3 goes to netbeans.org. Should it instead go to the latest JDK download site? https://www.oracle.com/java/technologies/javase-downloads.html
Or the Oracle Java Archive where they can choose the version to download? https://www.oracle.com/java/technologies/oracle-java-archive-downloads.html

And on the "Understand IGB development workflow" page > "Functional review" where it talks about the topic branch installer, it was helpful to me to be told that the 'installer' was referring to the 'exe' file. So I think adding something about that to the Functional review section would be helpful for on-boarding.

Thanks for the feedback Logan Weidenhammer !

Ready for PR.

Should I create a pull request from my fork's master branch to the lab's master even though the topic branch pipeline does not build?

The POM needs to be reconfigured.

Changes should always be made on a topic branch, which you then push to your fork. You then issue a PR from the topic branch on your fork to the master branch on the team repo.

Can you let me know if there is misleading documentation about that somewhere?

I think the documentation is good. The problem for me was understanding the effect of rebasing versus merging, so I did some reading on that. Confirming that the topic branch is used to create a pull request directly to the master branch on the team repo does help a lot.