search

mp4ra / mp4ra.github.io

MPEG-4 Registration Authority Web Site
https://mp4ra.github.io/
40 stars 28 forks source link

Travis-ci.org builds are not working anymore. #123

Closed podborski closed 3 years ago

podborski commented 3 years ago

Since June 15th, 2021, the building on travis-ci.org is ceased so the automatic deployments do not work anymore.

Looks like we have 2 options to solve this:

Any ideas?

dwsinger commented 3 years ago

ouch. what broke? your recommendation?

podborski commented 3 years ago

Every time we push something to a repo or accept a pull request travis is doing checks and deploys the website to master branch, which is connected to GitHub Pages.

Currently our travis configuration is not working anymore because it's configured for travis.org which now completely migrated to travis.com platform.

We could try to change the config settings to see if a quick fix is possible using the same yaml file and so on. But probably switching to GitHub Actions would be even better because it will not require 3rd party web hooks. But maybe someone has other opinion and we should stick to travis?

edrthomas commented 3 years ago

I think it is a good moment to switch to GitHub Actions, we wanted to do it anyway for ease of maintenance. I will get to it and keep you posted.

podborski commented 3 years ago

@edrthomas Ok. FYI. I already prepared a working PR https://github.com/mp4ra/mp4ra.github.io/pull/125, tested in my fork (seems to work).

edrthomas commented 3 years ago

@podborski Yes, I just saw after doing some tests on my side. I took the action you found for publishing and pushed the result.

From my side, the publishing action is working again and the latest commit has updated the website with the commits of the past weeks.

Please check this is correct, thanks !

podborski commented 3 years ago

@edrthomas can it be that the site is published before the test are run? Should we put everything in a single yaml file?

edrthomas commented 3 years ago

I gave some thoughts and I went for this. But, it is good we discuss it here. I didn't want the publish jobs to be triggered by pull requests but only the check script in those cases. Each workflow is currently well configured for this.

But you are right that if you push something directly to dev branch, you may publish it regardless of the check script outcome. But in the normal workflow, we would receive PRs and detect the issue within the PR.

To avoid the case you mention, when we push to dev directly, we could configure this https://docs.github.com/en/actions/reference/events-that-trigger-workflows#workflow_run which conditions the execution of a workflow based on the outcome of another.

Alternatively, we could merge into one workflow as you suggest but how do we prevent the entire publish jobs to be executed in that case for PR?

Any preference?

podborski commented 3 years ago

I think this is good enough for us at the moment. Thanks. I'll close this issue and the corresponding PR as parts of it are already merged.