> This is internal software, not intended to be consumed outside of the ASF
Well some things will be useful for people outside too (i.e. I am using the stash action outside of apache/) and we can't really prevent use from outside (I guess we can add a disclaimer? No idea what's legally required, after all the whole 'release as an act of the foundation' thing is a legal protection). > 1-10 -> monorepo, > 20: multiple repos. Between 10 and 20 both are good I think that's a sensible scale. Regarding your point in 3. that we should keep the number of actions low, we previously discussed forking solo-maintained actions that projects want to use into the repo for security but depending on the potential users for the actions, projects could add them to their own repos too. Am Do., 13. März 2025 um 18:57 Uhr schrieb Jarek Potiuk <ja...@potiuk.com>: > > 1. I think we do not need a voting process. This is internal software, not > intended to be consumed outside of the ASF - so more similar to asf.yml > than our projects. I find that usually slowing down and formalising review > and CI tooling that is used to develop a software, does more harm > than good. You anyhow need to have some exceptions and quick ways of doing > things (See today's problems with .asf.yaml) - and I think flexibility and > adaptability trumps the "quality" and "stability". While we should have > tests and reviews, they should not be IMHO mandatory. > > 2. agree with arguments, but I would downplay "intended for marketplace" > (our software is not), " larger download" (there is very little chance our > repo will grow to anything that < 0.5 s checkout time). We can also use > CODEOWNERS feature (bad name I know) to have a per-action group of people > who will be notified and automatically added for reviews . Also the > length of the URL is somewhat "meh" (and multiple repos is not as bad - it > shift it from folder to repo name - we will never have > `apache/stash-action@v1` , more likely we should compare > `apache/instastructure-actions/stash/restore@stash/v1` with > `apache/infrastructure-actions-stash/restore@v1` (but yes tag name has to > repeat action name in this case so it is slightly longer). > > Obviously (from the above), I prefer monorepo. But If that's unpopular, I > am also fine with multiple repos. > > 3. Not sure if it's worth it to be honest. I think also the choice of > monorepo vs. organization + multiple repos really depends on how many of > those actions we expect to have: 1-10 -> monorepo, > 20: multiple repos. > Between 10 and 20 both are good. I personally think that we should aim for > a low number of highly-specialized actions (that also determines my > monorepo preference). There are a handful of things that are really > specific to ASF and tens of thousands of actions out there. Rather than > having our own action, my default would be (in that sequence) to use the > existing/external one adapting my patterns, contribute to the existing one > if they miss a feature or flag, and at the last resort develop our own when > we have a really specific need, shared between different projects. > Maintaining a big number of such actions adds some overhead on maintaining, > updating, upgrading, fixing etc. etc. and I am not sure if we want a large > number of moving parts managed this way. > > J, > > > > > > > > On Mon, Mar 3, 2025 at 12:32 PM Jacob Wujciak <assignu...@apache.org> wrote: > > > Hello Everyone! > > > > I feel like we made good progress so far and the existing actions are > > being used but I think we have a few things to discuss that are about > > the process/administrative side of things. Some people discussed some > > of these in either slack or gh issues but I wanted to give it some > > focused attention on this ML: > > > > 1. Versioning and releasing actions > > What is the process? Normal asf release? Something simpler? This also > > touches on the next point > > > > 2. mono-repo vs one repo per action > > I am going to list the arguments pro and contra use of monorepo in > > random order, please feel free to add some if I missed anything. > > + Community building is easier > > + One place to watch > > - versioning/tagging harder (though thanks to Pavan dependabot now > > supports tags for actions in monorepos!) > > - larger download needed for CI (there is no way to do a sparse > > checkout for actions), this will be a bigger problem over time > > - no way to watch just one action, might deter regular contributions > > - one repo per action allows publication to the marketplace and is the > > intended architecture > > - long names for `uses: > > apache/instastructure-actions/stash/restore@stash/v1` vs > > `apache/stash-action@v1` > > > > 3. repo name, as shown above the current name is quite lengthy and > > especially if we would stick with the monorepo. From my understanding > > of Github Enterprise it should be possible to create a new org under > > the Apache Enterprise Github that basically acts as a namespace but > > uses the same runner contingent, settings etc. [1]. I feel like that > > would be the best of both worlds with an `apache-actions` org -> `uses > > apache-actions/stash@v1`. Contributors can watch the repo they are > > interested in without noise but it's still easy to get an overview of > > all actions through the org -> Community. > > > > I don't know if this is feasible at all and will of course defer to INFRA > > :) > > > > Best > > Jacob > > > > [1] > > https://docs.github.com/en/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-organizations-in-your-enterprise/adding-organizations-to-your-enterprise#creating-a-new-organization > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: ghactions-unsubscr...@infra.apache.org > > For additional commands, e-mail: ghactions-h...@infra.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: ghactions-unsubscr...@infra.apache.org For additional commands, e-mail: ghactions-h...@infra.apache.org
