Complete Release Workflow

[rpoet-jh]

This is a workflow that will release all PASS modules. It builds on the approach in the Release Java Modules. The workflow requires a Release Version and Next dev version as input. In order to run the workflow, a PAT needs to be set like instructed in the Release Java Workflow instructions.

I tried to make the workflow so that is can be re-run in the case where one of the steps fails for some reason. As one can see, there are several steps where failure can occur, so the workflow may not be re-runnable in all failure scenarios, but should cover the most common cases.

I will work on updating the release documentation once this workflow is reviewed/merged.

Note, I had to merge an initial version of pass-complete-release.yml to main so I could run tests, thus the diff in the file instead of being new.

[rpoet-jh]

@markpatton I was looking around at the repos and actions, and I think for the Snapshot steps in this workflow, the only thing that we really have to do is update the version to dev next version and push the commit. The building/publishing/docker image pushing all look to happen already in existing workflows in each repo. I think I can remove all those steps from the complete workflow, right?

[rpoet-jh]

@markpatton I was looking around at the repos and actions, and I think for the Snapshot steps in this workflow, the only thing that we really have to do is update the version to dev next version and push the commit. The building/publishing/docker image pushing all look to happen already in existing workflows in each repo. I think I can remove all those steps from the complete workflow, right?

@markpatton actually, looking at this closer, there is an issue with how I have commits pushing for the release and snapshot for each repo. Each push will start the main push trigger workflow in the respective repo, which we don't want for the release version I think. I will have to think about this a bit. Maybe we can chat on Thursday when my conference is done.

[rpoet-jh]

@markpatton actually, looking at this closer, there is an issue with how I have commits pushing for the release and snapshot for each repo. Each push will start the main push trigger workflow in the respective repo, which we don't want for the release version I think. I will have to think about this a bit. Maybe we can chat on Thursday when my conference is done

@markpatton sorry for the multiple comments, but I think I can clean this up by using a tag-ignore in the on push event in each of the workflows in the repos that are triggered on main pushes. I will change the complete workflow to include a tag that will cause the repo push workflows to ignore the pushes that come from the complete release workflow.

[rpoet-jh]

@markpatton sorry for the multiple comments, but I think I can clean this up by using a tag-ignore in the on push event in each of the workflows in the repos that are triggered on main pushes. I will change the complete workflow to include a tag that will cause the repo push workflows to ignore the pushes that come from the complete release workflow.

@markpatton I have made the following changes to address this issue:

• Added a tag command in the Snapshot commits that will tag each repo for the initial Snapshot version with <dev-next-version>-init. This tag will be pushed to the repo origin.
• Opened the 5 linked PRs. Each PR is updating the workflows that trigger from pushes to main so that they don't trigger if the commit has a tag. The only commits that have tags now are when we do releases.

Once the 5 PRs have been merged, I will run another RC release test.

[markpatton]

This is really well done and should save a lot of time.

The tag checks and careful organization means this should be able to be restarted again with most transient failures.

The use of tags together with atomic commits and modifications to the other repo workflows to avoid building the dev versions again is a great optimization.