On Wed, Jan 6, 2021, 8:39 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > > > > > > > Btw this is really not ideal if the action is docker based like the > GitHub > > SuperLinter. Rebuilding this takes forever if it does not pull the > > existing container. > > > > I belive super linter is an official GitHub one. All official actions that > are > GitHub owned are 'business as usual'. And I think you do not need to > rebuild the > images once, possibly copy it to your repo and refer from there. We are > doing > exactly this in airflow: > > 1) We have very simple scripts to rebuild the images that we use in our CI: > https://github.com/apache/airflow/tree/master/scripts/ci/dockerfiles
I am aware of how to use Docker in our build jobs... I am talking about Docker based GitHub Actions. They can have published docker images that they used so they do not get rebuilt all of the time. I called out SuperLinter as just an example. > > > It's hard enough to keep workflows in sync across multiple repos as it > is, > > and this year GitHub is planning on releasing features to make that > easier > > to share common definitions. Submodules for Actions is likely going to > add > > a whole lot more friction to this process. > > > > This is very little effort and no maintenance at all. It's just a little > bit more effort > than to add action "as usual": > > This is very little change, but it is WAY more secure, because not only it > forces > to review whenever it changes, but it automatically stores the SHA of the > repo > in the commit, without even thnking about it. > > I do not think there is much of a maintenance difference. If anything it > is simpler > with submodule because the only thing you need to do is > > git submodule update --remote potiuk/get-workflow-origin > > > Then in the PR you review the code (which you MUST do anyway). That's it. > Your workflow is not our workflow... We have 4 different repos that have very similar sections to the yaml that currently we have to keep in sync including branches. GitHub knows this is a pain and is going to be supporting shared workflows to help support this, we should not be working against this. > > > > Also as for banning the git credentials bit in checkout please make sure > > you keep in mind the different workflows that people have. Are we not > > going to be able to auto push our website? > > > > Absolutely not. This is precisely where we use the action (of my friend > BTW) https://github.com/ad-m/github-push-action > > It requires GITHUB_TOKEN to be passed and once you add it via submodule > you can review it and use it to push your changes to your or another > repo. > > Creating custom actions for each time I need to use the token... I am sorry but I hope this does not become policy I don't see how any of this really helps beyond what we get from pinning to SHAs or approved actions. Anything else is creating developer friction for minor gains which just makes for complicated less secure systems. --Brennan
