Fix build components scripts to install MET and other METplus components

[georgemccabe]

Currently the build_components/build_MET.sh does not work as intended.

This issue needs dtcenter/MET#1920 to be completed before it can be completed.

Describe the Enhancement

Get the script to work.

Here are some notes of some of the changes that are needed:

• Cannot run ./build_components/build_MET.sh because commands assume running from build_components directory
  • add cd "$( dirname "${BASH_SOURCE[0]}" )" to beginning to change into directory containing script
• Externals_stable.cfg : branch cannot be a tag
  • change all to main_vX.Y, i.e. v10.0.0 to main_v10.0
• Add git ignores for MET, METdatadb, METviewer and other files downloaded into build_components i.e. tar_files, gfdl tracker, etc
• QUESTION: why include wget and curl commands in build_MET.sh script? Why not just use curl?
• GFDL tracker cannot be installed with GNU with the version downloaded in script, but example env_var.bash uses gnu. There is a process to installing with GNU that is listed in ci/docker/docker_env/Dockerfile.gfdl-tracker
• This command fails because this file does not exist: tar -xzvf compile_MET_all.sh.tgz

Time Estimate

1-3 days

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

Define the source of funding and account keys here or state NONE.

Define the Metadata

Assignee

• [ ] Select engineer(s) or no engineer required
• [X] Select scientist(s) or no scientist required

Labels

• [X] Select component(s)
• [X] Select priority
• [X] Select requestor(s)

Projects and Milestone

• [X] Select Repository and/or Organization level Project(s) or add alert: NEED PROJECT ASSIGNMENT label
• [X] Select Milestone as the next official version or Future Versions

Define Related Issue(s)

Consider the impact to the other METplus components. Changes in other repositories may be needed to get this to work.

• [ ] METplus, MET, METdatadb, METviewer, METexpress, METcalcpy, METplotpy

Enhancement Checklist

See the METplus Workflow for details.

• [ ] Complete the issue definition above, including the Time Estimate and Funding Source.
• [ ] Fork this repository or create a branch of develop. Branch name: feature_<Issue Number>_<Description>
• [ ] Complete the development and test your changes.
• [ ] Add/update log messages for easier debugging.
• [ ] Add/update unit tests.
• [ ] Add/update documentation.
• [ ] Push local changes to GitHub.
• [ ] Submit a pull request to merge into develop. Pull request: feature <Issue Number> <Description>
• [ ] Define the pull request metadata, as permissions allow. Select: Reviewer(s) and Linked issues Select: Repository level development cycle Project for the next official release Select: Milestone as the next official version
• [ ] Iterate until the reviewer(s) accept and merge your changes.
• [ ] Delete your fork or branch.
• [ ] Close this issue.

[georgemccabe]

Need to add item to METplus official Release Guide to update the build_components/Externals_stable.cfg file to include the tags for the latest coordinated release. Or come up with consistent way to handle this if possible. Some ideas include:

• Infer version of components based on current version of METplus and include a text file to include exceptions to the rule in case release versions get out of sync
• Investigate if the default branch can be easily specified to get that version of the code

[georgemccabe]

To expand on the previous comment, the tags in build_components/Externals_stable.cfg are not updated when a bugfix release of any of the components are created. We should come up with an approach to handle this. Some potential solutions include:

• When a METplus component bugfix release is created, create/update an X.Y-latest tag that matches the new bugfix X.Y.Z tag. Update the Externals_stable.cfg file to use this tag instead so it will always use the latest bugfix release.
• When a METplus component bugfix release is created, update the Externals_stable.cfg file in the METplus repo to increment the version.

The former seems like less maintenance overhead. It is also similar to how the DockerHub build hooks handle a bugfix release of METplus to get the latest MET Docker tag.

Instructions should be added to each METplus component's bugfix Release Guide steps to include this.