Andrew Q pipeline run

[coolkingcole]

testing pipeline for Andrew Quijano.

[AndrewFasano]

I'm fairly reluctant to merge changes to our CI as we can't really test CI in advance and it typically requires a series of PRs to fix the things each change breaks. There are a lot of different things going on here. I like some of them, but definitely don't think they should all be in a single PR. There are still lots of things mixed in/across commits in ways that make it hard to understand your changes.

Here's my best attempt to identify what's happening here and provide feedback. I'm very interested in merging the docs updates and action version increments. I'm worried the other changes will break things.

• b89176b3c91e662674118fa44f2335877394251f: deleting stale files - great
• b231c93d82aa9c7e29c0e006e5cd981d9f4932ba
  • Rename containers in debian/setup.sh - why? Seems harder to understand that there are 2 distinct containers now that they both have the same name
  • Update libcapstone to install v5 via git - good (I guess there's no v5 package)
  • Switch to installing libosi via a released package instead of git - great
  • Change install_ubuntu.sh to install pypanda as the local user (though without the --user flag?) - maybe best practice, but shouldn't be mixed in with these other changes
• 80c61245542b1f61b36848a868f9633975298320: update docs - great
• b1658c61dbf483866853602eb6564d8ffb785e2e
  • Update CI actions to new versions - this seems good and worth merging, even if we have to troubleshoot later
  • Break publish_docker here Not good
  • Rename containers/where they get pushed - I know we talked about this, does this resolve the issue where external collaborators can't have their PRs get tested (even after the PR is approved to run in CI)? If not, why risk changing this
  • Change build action for (unused?) panda_stable container - fine
• 50db25c62425e5366212b446f4dae406a042542b to update libosi version - looks good, should be squashed with changes in b231c93d82aa9c7e29c0e006e5cd981d9f4932ba (which could be split into multiple commits)
• 5fbc6d17884121d0cbfcfff32c7b9a98d4ffb6b9 to run ldconfig - looks good, should also be squashed with relevant changes in b231c93d82aa9c7e29c0e006e5cd981d9f4932ba.
• bd55fe817d8941d5ca15afe6cc449ddb8f640d91 merge commit / not sure if any of this matters / goes away if we rebase on main.
• 4eef1a8f456666951d3b7ccd58ab241762bdfb78 should be squashed with b231c93d82aa9c7e29c0e006e5cd981d9f4932ba.

[AndrewQuijano]

So as for my change to setup.sh, currently for deployment we:

1- create a panda_installer image up to installer target 2- create a panda image up to panda target

As this script is only used for deployment, I propose just creating one panda image, build up to installer, extract the wheel file, and continue to build until panda target to package the Debian package. This should speed up deployment quite a bit as we are running make for panda only once instead of twice, at least that is what I assume the "CACHED" means on the screenshots provided.

Here is the full run log https://productionresultssa7.blob.core.windows.net/actions-results/ccb307b3-5aa8-49f9-88f2-63447c0a8652/workflow-job-run-23cbbf46-0090-5639-7e11-ae079f190a1b/logs/job/job-logs.txt?rsct=text%2Fplain&se=2024-07-15T04%3A26%3A12Z&sig=E0aXzZEK6NmDb2r0dxEPnaIWOFOtOt7M4Q%2B0anbSMEw%3D&ske=2024-07-15T14%3A38%3A20Z&skoid=ca7593d4-ee42-46cd-af88-8b886a2f84eb&sks=b&skt=2024-07-15T02%3A38%3A20Z&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skv=2023-11-03&sp=r&spr=https&sr=b&st=2024-07-15T04%3A16%3A07Z&sv=2023-11-03

About creating pandare/panda_test, the issue is that external users can't push to ghcr.io/pandare, so I propose we cache on DockerHub, since sharing a secret is easier than creating a shared account. Based on what I read, it seems the solution then is to call a Workflow dispatch button, so that then the external PR workflow can access the dockerhub secret and cache the image in DockerHub. It seems like the caching worked just fine. Unfortunately, it seems like there is no way to know if this will work until it is merged and when an external party submits a PR. But I'd say this meets both security needs as dispatch workflow can only occur manually, but would allow external users to use the cached dockerhub API token to cache a test panda container.

https://docs.github.com/en/actions/using-workflows/manually-running-a-workflow

P. S. For libcapstone, I just followed what you did on the Dockerfile https://github.com/panda-re/panda/commit/f861fb3772a9e9150487c38a9adba1a8d48b23a6

[AndrewQuijano]

Everything should be addressed on this branch: https://github.com/AndrewQuijano/panda/tree/cole-updates

[AndrewQuijano]

And I raised the issue to get a Debian package for Capstone, seems like whenever v6 comes out, we will finally get a package

https://github.com/capstone-engine/capstone/issues/2398