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 <[email protected]> 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 <[email protected]
> >:
> >
> > 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 <[email protected]>
> 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: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--
Cheers,
Drew Foulks
ASF Infra
