add release action to upload generated distribution file

[rem1776]

Description
adds an action workflow to trigger when any <year>.<version>[.<patch>] tag is created that will create a new release draft and upload the tarfile created by make dist. Once the tag is created and the action runs, the release will be a private draft until someone edits it and hits publish. The draft is set to include the same automatically generated release notes github creates.

Here's an example from my fork after I published it, with the make dist generated tar file:

https://github.com/rem1776/FRE-NCtools/releases/tag/2025.14

The uploaded tarfile name will follow whatever version is set in configure.ac, regardless of the tag.

I used ubuntu package installs in lieu of a custom image since I can't seem to get past errors building the docs with my spack based images.

This is a draft since the CI is failing right now, thats why I have some build changes in here to get it working. I think it just needs seth's next PR merged and then I'll get rid of any changes besides the workflow yaml.

How Has This Been Tested?
CI

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules
• New check tests, if applicable, are included
• make distcheck passes

[ceblanton]

hey @rem1776 Seth's big update went in, so this might pass now after the merge conflict

[mlee03]

I'm missing something, why is this PR needed?

[ceblanton]

@mlee03 this was my suggestion inspired by a recent problem. There was a bug introduced to 2024.05.01 (https://github.com/NOAA-GFDL/FRE-NCtools/releases/tag/2024.05.01) that prevented split_ncvars.pl from calling list_ncvars. @underwoo hand-fixed it in the installed location, and fixed it in the main branch here,

#354

which had the intent of bumping the tag to 2024.05.02, and did update it in configure.ac, but did not actually tag the repository.

Then, when @HansVahlenkamp redeployed FRE-NCtools in the latest SW environment 2025.01, he redeployed the bug.

The slight confusion between the repository tag and the configure.ac version contributed to the problem. @rem1776 has encountered and solved this problem in the FMS repositories, I believe, so I suggested some of the CI goodness come to FRE-NCtools as well.

[ceblanton]

@rem1776, is it possible to set the configure.ac version to be "dev" except during the tagging and releasing process?

@bensonr had suggested that this is possible, and I think it would be helpful and related here. If it's not feasible, than this PR is still a huge improvement that we should accept.

[mlee03]

got it, one more question why was split_ncvars/split_ncvars-p removed?

[rem1776]

@rem1776, is it possible to set the configure.ac version to be "dev" except during the tagging and releasing process?

@bensonr had suggested that this is possible, and I think it would be helpful and related here. If it's not feasible, than this PR is still a huge improvement that we should accept.

Yes I can add that to this pr. The way it works is when a release is created, it triggers a PR to be created that appends the "-dev" in the configure.ac. Then we would just remove it before tagging a release.

[rem1776]

got it, one more question why was split_ncvars/split_ncvars-p removed?

Oh my bad left that in by accident. Needed it before the build changes went through I'll remove it.