Update docker image used as part of github actions to be hosted on github packages. about tflite-micro HOT 3 CLOSED

I have spent some time with the Github Container Registry (ghcr) and it is fairly straightforward to use from actions. The trick is getting the container in there.

The easy way to do this is to create a manually run action that uploads the image, this is fairly simple and uses the GITHUB_TOKEN secret to access the tensorflow organization's account on the ghcr. The only problem here is dealing with forked repos, which won't be able to use the action without it failing because their GITHUB_TOKEN isn't going to have access since it isn't coming from the tensorflow organization.

The only other way to do this would be to have someone with organizational access manually upload the container on any changes to the container.

Note that this workflow action wouldn't run automatically at any point. You have to go into actions and manually trigger it. And the only downside to someone without access running it is the job would fail.

I would do the manual workflow action but need your call on it @advaitjain.

from tflite-micro.

I have this working in the latest PR #30 . Using PULL_REQUEST_TARGET didn't work as expected with the github token and the container repository using private images, using WORKFLOW_RUN does. As outlined in the PR comments, we aren't able to use the github token to access private images outside the organization, there is just no option to allow that kind of access from the container permissions side. Even if you are an admin of an org, a container put in your account's registry space has no option to allow repositories outside your account repos to access the container from automation using the github token. But you can get around this with a PAT token, which is what we are doing right now.

When/if ghcr functionality is activated in the tensorflow org this will stop being a thing and we can use an internal access only container in the tensorflow registry space and the github token which is better practice for a lot of reasons.

Using the WORKFLOW_RUN trigger setup is pretty cool because it gives us two levels of privilege. The first is the read only restrictions that have been super annoying so far. But after the restricted workflow runs, another workflow with full access launches. The only annoying bit is that there is complete separation between the two workflows. Like the workflow_run triggered file doesn't even get the context of the PR or branch ref at all, so everything passing between the two jobs has to be sent using the github artifact system. This is actually a smart security feature and I am messing with it right now to get it passing whatever we might need.

from tflite-micro.

tested with #157 that the check is now working as expected.

from tflite-micro.