But that's just it, this isn't a CI system. It could be used for CI, but
it's capable of much more (and fwiw I don't think curl can actually do
that specific thing, since you'd need to parse HTML and it's not capable
of that - plus credentials and webhooks etc. etc.).
For example, consider the Python client. A while ago I started
publishing a mirror under my own username on PyPi. This is because
nobody wanted to do the manual work of publishing an update every time
the client changes, which is fair (in fact I'm not very good about
keeping it up-to-date either). But with actions that publishing could be
automated on a per-release or per-change basis.
I really think this is something worth exploring, even if we don't want
to use it for CI - though I still think that's an attractive use-case
even if only to avoid needing to do 'ok to test'. But that summarizes
everything I have to say, I think, so if we still think it's a bad idea,
then I'll drop it.
On 8/5/19 4:09 PM, Gray, Jonathan wrote:
I'm -1 on the idea of having multiple CI systems in play. If you really want
to auto-tag things, a properly crafted curl statement can do it.
Jonathan G
On 8/5/19, 4:06 PM, "ocket8888" <[email protected]> wrote:
Well even if we still need something else for CI, actions can be used to
trigger it. Then everything else can be run from GItHub, without
over-taxing the limited CI resources afforded by the ASF. Actions can
also be used for things that aren't CI-related at all, like
automatically tagging bug reports properly, since non-committers can't
do it themselves. Go tests are just a starting point, and unfortunately
there's no other way to test.
On 8/5/19 2:10 PM, Gray, Jonathan wrote:
> That's presently on the todo list for OSS.
>
> Jonathan G
>
>
> On 8/5/19, 12:22 PM, "ocket 8888" <[email protected]> wrote:
>
> Well maybe we don't wind up using it. It's just an experiment at
this point.
>
> But also: does our current CI system use CiaB? Is it a hard
requirement
> that our actions be a full CI system? Is there a problem with using
> workflows to trigger 'real' CI when necessary?
>
> On Mon, Aug 5, 2019 at 12:03 PM Gray, Jonathan
<[email protected]>
> wrote:
>
> > I wouldn't pollute master and our GH if we don't have a
reasonable belief
> > it _might_ be able to meet our present CI requirements.
> >
> > Jonathan G
> >
> >
> > On 8/5/19, 11:42 AM, "Fieck, Brennan" <[email protected]>
wrote:
> >
> > > maybe do you want to explain for the group which "actions"
you are
> > attempting to enable?
> >
> > An action is basically just a docker image that gets run. The
one I'm
> > doing just runs Go tests every day at midnight.
> >
> > > can it leverage CDN-in-a-Box?
> >
> > possibly, but I honestly doubt it. I could conceivably write
an action
> > that uses docker-compose to bring up CDN-in-a-Box, but since
you're limited
> > to two concurrent actions I'd be surprised if they let me spin up
that many
> > other containers.
> > ________________________________________
> > From: Jeremy Mitchell <[email protected]>
> > Sent: Monday, August 5, 2019 11:34 AM
> > To: [email protected]
> > Subject: Re: [EXTERNAL] GitHub Actions
> >
> > although not ideal, i don't have a real problem with you
experimenting
> > on
> > master if that's the only place these actions work. maybe do
you want
> > to
> > explain for the group which "actions" you are attempting to
enable?
> >
> > On Mon, Aug 5, 2019 at 11:08 AM ocket 8888
<[email protected]>
> > wrote:
> >
> > > So it turns out actions will only run on master. I've
opened a PR
> > from the
> > > dev-actions branch:
> > https://github.com/apache/trafficcontrol/pull/3774 so
> > > does anyone mind my doing that instead? Of course, if it
does get
> > merged I
> > > can delete my branch - or the merger can.
> > >
> > > On Fri, Aug 2, 2019 at 10:06 AM Jeremy Mitchell <
> > [email protected]>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Fri, Aug 2, 2019 at 10:01 AM Robert Butts
<[email protected]>
> > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > I'm in favor of being liberal with experimental things.
Just
> > name it
> > > > > something someone won't mistake for anything stable or
> > release-ish,
> > > > > "dev-githubactions" or whatever. And delete it if/when
you're no
> > longer
> > > > > using it.
> > > > >
> > > > >
> > > > > On Fri, Aug 2, 2019 at 9:22 AM Gray, Jonathan <
> > > [email protected]
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Nope, I've done similar things in the past for
Jenkins (and
> > it's on
> > > my
> > > > > > todo list again, so I'm curious what you find out).
> > > > > >
> > > > > > Jonathan G
> > > > > >
> > > > > >
> > > > > > On 8/2/19, 8:54 AM, "ocket 8888"
<[email protected]> wrote:
> > > > > >
> > > > > > I wanted to mess around with GitHub actions for
Traffic
> > Control -
> > > > but
> > > > > > they're in beta and I haven't been granted access
to them
> > as a
> > > > GitHub
> > > > > > user.
> > > > > > But Apache as an organization has. So basically,
I can
> > mess with
> > > > them
> > > > > > on
> > > > > > the ATC repo, but not on my personal fork.
> > > > > >
> > > > > > For that purpose, I was wondering if anyone would
have a
> > problem
> > > > with
> > > > > > me
> > > > > > making a branch where I could tinker with it a
bit? I can't
> > > imagine
> > > > > > how it
> > > > > > would affect anything outside of the branch, and
at any
> > rate the
> > > > > > branch can
> > > > > > be deleted at any point.
> > > > > >
> > > > > >
> > > > > > (GitHub Actions:
https://github.com/features/actions)
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
>
>
