BUG: deploying onyo-demo is not working anymore

[TobiasKadelka]

I am stil trying to identify the exact problem, but want to share/document what I found in case somebody else knows how to solve the problem.

Here an example deploy-demo workflow that failed:
https://github.com/psyinfra/onyo/actions/runs/7625219190/job/20769022194
Scrolling to the end shows this error at step "push to onyo-demo":

push to onyo-demo
remote: Support for password authentication was removed on August 13, 2021.
remote: Please see https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories#cloning-with-https-urls for information on currently recommended modes of authentication.
fatal: Authentication failed for 'https://github.com/psyinfra/onyo-demo/'
Error: Process completed with exit code 128.

This fails because of these two lines in .github/workflows/deploy_demo.yaml; the second line is the point of failure, but as far as I can see, the problem is setting the location of the onyo repo incorrectly:

          printf '\nset the location of the demo repo\n'
          git -C /tmp/fresh_demo remote add origin https://aqw:${ONYO_DEMO_ACCESS_TOKEN}@github.com/psyinfra/onyo-demo

          printf '\npush to onyo-demo\n'
          git -C /tmp/fresh_demo push --force --set-upstream origin 

[aqw]

The access token may have expired. I can look at this later.

[aqw]

Ok, I found a better solution (because the access tokens have a max ttl of 1 year).

GitHub automatically sets up tokens to allow jobs to push back to their own repo. So the ideal solution is:

1. Remove the push part from the onyo tests. But keep the rest of the onyo demo generation. It's a useful test.
2. Add a GitHub Actions workflow to the demo repository, and have it run daily. It should pull from the onyo repo (unprivileged), run the demo generation, if successful, push the results to its own repo.

This way, it never expires, and we don't need to deal with secrets across repos.

[TobiasKadelka]

Since workflows are defined in the directory .github/workflows/ this might mean we have to add them at what you describe at some point during the demo-repo-generation so that it automatically gets pulled into the demo repo.
Otherwise I think this might "overwrite" the workflow you want to have after the first "pull" of the demo repo from the main onyo project.

So while I like your proposed solution, it needs a bit more effort to make sure it actually works like we want it to ;)

[aqw]

It can be stored in a different branch.

[TobiasKadelka]

A little update on the progress:
I build a test repository https://github.com/TobiasKadelka/test-repo-onyo-demo

This contains a branch "setup" with a workflow which pulls the current demo repository and pushes it to the main branch of the test-repo.
The next steps are:

• generating the demo repository in a branch "demo" of the main repository (instead of pushing it to the demo repo)
• adjusting and my script from the test-repo to pull that demo branch
• adjusting it also to run daily, based on https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
• pushing my script to the demo repository so that it runs from there

[TobiasKadelka]

I have somewhat bad news in regards to the new idea of how to deploy the onyo demo.

In short: "scheduling" a CI workflow (automatically starting it regularly like cron) does exclusively work for the default branch (most often main), which is also the branch that gets displayed by default when going to an URL for a repo without specifying the path (https://github.com/psyinfra/onyo shows the main branch).
See also here for other peoples frustrations: https://github.com/orgs/community/discussions/16107
Otherwise scheduling works well --- just not in the default branch.

---

That leaves us with the following possibilites:

1. add the CI workflow file to the demo in the onyo repository (while building it) from which we want to pull the demo repo

• contra: when somebody clones the demo, they have our CI workflow file in there, which is not really onyo
• pro: relatively clean and gives us everything else we want

2. have the default branch of the demo repository with the workflow file, the demo repository will live there in a different demo branch that is not the default one, which then needs for example the URL https://github.com/psyinfra/onyo-demo/demo (the last "demo" specifying the branch)

• big contra: basically the same as just having a demo branch in the main repository, which we did not want in the first place
• pro works and provides a "clean" demo repository, just in a branch
• whoever finds the onyo demo repository does this probably via the docs or readme, hence having to specify the demo branch in the URL kind of does not matter, except estatically

3. Just doing it like we already did for a year and just update the access token

• pro: they might add scheduled CI to non-default branches during the next year
• pro: simple, too
• contra: worst case we have to add a new access token once a year

[aqw]

I think option 1 is what we should pursue.

This is a use-case for .onyoignore. And I think it's a valid use-case that onyo repos might indeed have CI for various checks, etc.

[TobiasKadelka]

Cool, I will work on this later then. The necessary steps as far as I see them are:

1. adding an .onyoignore to the demo-build
2. adding an adjusted form of the script https://github.com/TobiasKadelka/test-repo-onyo-demo/blob/setup/.github/workflows/deploy_demo.yaml to the demo-build

• remove the "on push" part to just use the scheduled CI part
• set https://github.com/psyinfra/onyo/demo as remote to pull demo from
• adjust time of the day when to pull the new demo

3. pushing the new version of the demo repository one time to https://github.com/psyinfra/onyo-demo one time to start using the new demo