On Thu, Jan 7, 2021 at 7:29 PM Matt Sicker <boa...@gmail.com> wrote: > GitHub supports SVN to an extent, but it's more of an SVN view of a > Git repo. Try it out: > > svn info https://github.com/apache/whimsy/ > > Path: whimsy > URL: https://github.com/apache/whimsy > Relative URL: ^/ > Repository Root: https://github.com/apache/whimsy > Repository UUID: 54ef964a-1539-08b0-68b0-ce57b7db7bff > Revision: 7588 > Node Kind: directory > Last Changed Author: sebb > Last Changed Rev: 7588 > Last Changed Date: 2020-11-23 06:08:13 -0600 (Mon, 23 Nov 2020) >
Cool. Nice from GitHub they do that :) Nice from GitHub they are allowing svn clients. I wonder if svn externals are supported the same way. That would be an equivalent if anyone who still uses subversion would like to use a similar workflow (and use GitHub Actions as well). Maybe someone who uses both could check it. Just to remind everyone (Vladimir mainly as it seems the discussion is mainly between us) what I am proposing here is just the way how we've done that at Airflow. This is what we found after few iterations is great balance of security and usability - with very limited (almost none) impact on the current workflow and somehow improving it (like built-in submodule review is a game changer for me). I am not saying this is the only solution, just one I think works well and solves the problem that infra identified. And my recommendation would be that this becomes "best practice". It's infra's decision eventually not mine I think eventually some kind of scanning and flagging misuse of the actions is inevitable and sooner or later everyone in ASF will have to follow, this way or the other. To what extent it will be enforced - again It's more of an infra's decision. Also whether it is applicable to everyone, every repo, every project - I have no idea. I just wanted to share it with others so they can make informed decisions (and prepare for what's coming from infra). If anyone decides to bypass the requirements/policies which infra imposed. it's their own decision. > On Thu, 7 Jan 2021 at 12:23, Jarek Potiuk <ja...@potiuk.com> wrote: > > > > On Thu, Jan 7, 2021 at 6:56 PM Vladimir Sitnikov < > > sitnikov.vladi...@gmail.com> wrote: > > > > > What I mean is that there's a trivial workaround which does not require > > > significant changes to the repository layout. On top of that, it does > not > > > change developer's workflows (they do not need to learn submodules) > > > > > > > This is a wrong assumption of yours. > > > > Only those who add actions need to learn about submodules. Usually those > > will be CI-masters. No user/contributor needs to know about them. > > No user workflow is impacted whatsoever. > > > > > > > > > > On top of that, git submodules are NOT available for SVN repositories. > > > > > > > We are talking about GitHub Actions. Please correct me if I am wrong, > > but Github does not have SVN repositories, but surely you know that. > > > > > > > That works for trivial actions only. GitHub diff can't show the diff > of 2-3 > > > megebyte javascript files. > > > GitHub can't diff Docker images and so on. > > > > > > > Surely. Noone can do it effectively with or without GitHub. > > I believe you should not be allowed to run action that you are not > > able to review. If you do, you put your project and ASF ar high > > risk. Again to repeat. unreviewed action might modify your repository > > (unlike any other 3rd-party stuff you add). This is the threat we > > are protecting against. > > > > > > >The sheer fact that you have not done it > > > in your example > > > > > > 1) I am the owner of burrunan/gradle-cache-action, so it is > more-or-less > > > fine that I trust myself. If somebody takes over my GitHub id, then the > > > issue with action sha is the least harmful thing. > > > > > > > You did not say it when you showed you as an example (that potentially > > other > > people might follow). Even if you did, I strongly advise you treat my > > actions the > > same way as any other. This is a basic assumption > > as it might serve as an example for others. All actions in our workflows > > (including my own) were using commit SHA . Thanks to that everyone who > > adds a new action will be more likely to follow the same pattern. > > > > > > > 2) Of course the references can be switched to commit ids, however, I > am > > > inclined to avoid combining multiple changes at once. Currently it is > > > obvious that the tag is the same as before workaround. > > > > > > > Again is the matter of 'thinking' this way. Showing examples to other > people > > with non-best-practice is a bad idea. This is a flawed example, sorry. > > > > > > > > > > Vladimir > > > > > > > > > -- > > +48 660 796 129 > -- +48 660 796 129
