> "What parts of GHA seems like a thing we need to understand better before we do too many more of these things."
What parts of our release policy applies to custom GH actions seems like a thing... On Fri, Mar 14, 2025 at 8:22 AM Drew Foulks <dfou...@apache.org> wrote: > Hey all, > > My current understanding is that this is primarily internal tooling so > we're not really _releasing_ software per se, though that's subject to > change. Additionally, I don't think that this group is in danger of > becoming something so formal as a TLP. > > > "flexibility and adaptability trumps the "quality" and "stability". > > I agree that we don't need to re-invent every wheel, and that most of > these actions should facilitate internal processes.There will be likely be > some that should be handled with care (e.g. stash), but in the end I think > we'll find those to be relatively few. > > > "Obviously (from the above), I prefer monorepo. But If that's unpopular, > I am also fine with multiple repos." > > <Infra Hat> > Right now, the way that the ghactions group is supported is > through GitHub only, This would need some formalization (read: an infra > ticket) to be supportable by our current system for multiple repos. > It would honestly benefit from that anyway, > </Infra Hat> > > > "No idea what's legally required, after all the whole 'release as an > act of the foundation' thing is a legal protection)." > > What parts of GHA seems like a thing we need to understand better before > we do too many more of these things. > > I've cc'd a few people that I think might be able to weigh in on release > policy. > > > On Thu, Mar 13, 2025 at 2:20 PM Jacob Wujciak <assignu...@apache.org> > wrote: > >> > 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 >> >> > > -- > Cheers, > > Drew Foulks > ASF Infra > > > -- Cheers, Drew Foulks ASF Infra
