Trigger CI on edited tag; but only for edits to merge target (base)

[markcmiller86]

No description provided.

[markcmiller86]

I am not sure this is worth the trouble. It is some more complex logic that aims to a) properly re-trigger CI if the PR is edited by adding edited as one of the PR state transitions (types) to follow.

But it should do so only if a PR is edited in specific ways. For example, edits to a PR's title or opening comment should not re-trigger CI whereas edits to the base (target) of the merge should.

The alternative is to leave edited out of the types to follow or suffer CI re-triggers whenever trivial edits to a PR occur. Because Silo's CI can also be triggered manually whenever needed, its concievable the correct policy here is just to manually re-trigger CI in this or similar scenarios.

[markcmiller86]

So, I am deciding to close this pull request. In future, if base of PR is edited, the correct action is to re-trigger CI manually.

[sbryngelson]

@markcmiller86 can you create a new tag so users can point to it when using Silo? I don't particularly care what it's called.

[markcmiller86]

@markcmiller86 can you create a new tag so users can point to it when using Silo? I don't particularly care what it's called.

@junghans and @sbryngelson, a pre-release is available here, https://github.com/llnl/Silo/releases/tag/4.12.1-pre1

[sbryngelson]

@markcmiller86 is the best

[markcmiller86]

FYI...use 4.12.1-pre2 release assets. The release assets in 4.12.1-pre1 are bloated due to inclusion of ghpages subdir (for silo.llnl.gov website) which includes all prior .tar.gz releases.