search

tum-ei-eda / etiss

Extendable Translating Instruction Set Simulator
https://tum-ei-eda.github.io/etiss/
Other
29 stars 36 forks source link

GH-Pages are not automatically deployed anymore #63

Closed rafzi closed 3 years ago

rafzi commented 3 years ago

I seem to have accidentally dropped the job with this: https://github.com/tum-ei-eda/etiss/commit/ec9e71af6916ab835be38a5e321f406f9aab6e58

Do we want to use travis again or port the flow to GH Actions?

wysiwyng commented 3 years ago

I would just port this job to Actions, no point in having two different CI systems.

wysiwyng commented 3 years ago

A few options here:

  1. Trigger documentation build on every push to master
  2. Trigger only on version tags (v0.0.x)
  3. Trigger manually, button in Actions tab

I personally like 2 and 3 better, please discuss.

JoGei commented 3 years ago

A few options here:

  1. Trigger documentation build on every push to master
  2. Trigger only on version tags (v0.0.x)
  3. Trigger manually, button in Actions tab

I personally like 2 and 3 better, please discuss.

I'd say 2) is enough, 3) could/will lead to way out-of-date docs. 1) would also work, but is the doc build a huge overhead w.r.t. to verifying pull requests as pass?

wysiwyng commented 3 years ago

2 would imply of course that we need to actually start tagging ready-ish versions to have documentation built. Combinations of above possibilities are of course also thinkable.

PR #66 makes doc builds run in parallel to normal CI, so would not really impede anything. I would also only build the docs on pushes to the master branch, so that pull requests etc. don't overwrite anything.

wysiwyng commented 3 years ago

For other triggers see here: https://docs.github.com/en/actions/reference/events-that-trigger-workflows

The most interesting ones are probably already listed above.

rafzi commented 3 years ago

I'd say 1) is easy and most useful. Also does not require any change of workflow. Currently we don't use tags frequently enough.