search

viperproject / viperserver

HTTP server that manages verification requests to different tools from the Viper tool stack.
Other
10 stars 17 forks source link

Create Nightly Release Only on Change #40

Closed ArquintL closed 3 years ago

ArquintL commented 3 years ago

@fpoli will periodically create PRs when the Viper Tools change. To reduce the number of unnecessary PRs that are created even though the tools contained in the ZIP files have not changed, this PR compares the commit hashes of ViperServer, Silver, Silicon, and Carbon with those used for (already existing) nightly releases. A new nightly release will only be triggered in the viper-ide repository if at least one commit hash has changed. The check, as implemented in this PR, works because versions.txt stores the current commit hashes and is used as body of the nightly release. Thus, one can easily check the content of the current versions.txt file against the bodies of the releases.

aterga commented 3 years ago

I'm not an expert on Github CI, but the description makes sense to me, although I'm not sure I understand it precisely.

(The following comment is not specific to this PR.) For me, the easiest way to understand CI is visually, i.e. to draw a dependency graph that shows what-triggers-what. I recommend eventually drawing and keeping such a diagram somewhere, maybe in the Viper IDE repo or here. This is something that Jenkins could provide out-of-the-box, but I don't suppose such a feature exists when you configure CIs across multiple Github repos (although in principle it could exist)?

ArquintL commented 3 years ago

@aterga Good point, I can include something like that in the viper-ide's README. There is no "official" way of triggering a workflow of a different repo on GitHub. Instead, one has to make a POST request to an HTTP endpoint. Thus, it would be very hard to figure out what is triggered from where (in a generic way)