Hello everyone,
Coming back to the thread. Apache Beam project solved the problem in a slightly
different way than we did in Airflow, and I think it might be a bit better, so
maybe that can lead to a recommendation from the INFRA.
https://github.com/apache/beam/pull/13670
Rather than cloning t
Jarek>so maybe that can lead to a recommendation from the INFRA.
Please, no. The inclusion of the third-party code into the project
repository has non-trivial licensing implications.
GitHub Action should be treated not that different from any other project
dependency.
If infra team forbids action
>
>
> Please, no. The inclusion of the third-party code into the project
> repository has non-trivial licensing implications.
>
I do not think (but correct me if I am wrong) that this is the case.
I think once the licence is OK, it has very little implications. The
implications
are mostly when yo
Jarek>Actions are usually rather small
https://github.com/burrunan/gradle-cache-action becomes 3 megabytes of
JavaScript when compiled.
It takes a couple of minutes to build the action itself.
Jarek>but judging from some recent discussions
Jarek>this is very clear from legal point of view they on
I prefer constructive approach rather than criticising and complaining, and
I think we found (together with Ash) even better approach with submodules.
Daniel - I know you will be working on the infra side on that - I think you
should
consider making the below submodule approach the "highly recomme
On Wed, Jan 6, 2021, 7:31 AM Jarek Potiuk wrote:
> I prefer constructive approach rather than criticising and complaining, and
> I think we found (together with Ash) even better approach with submodules.
>
> Daniel - I know you will be working on the infra side on that - I think you
> should
> co
Website builds are handled by a specific deployment script that
doesn't necessarily need to give write access to GitHub Actions or
other builds. Unless you're talking about generating a static site and
committing it to git and then having it published? Which is also
somewhat supported for website b
On Wed, Jan 6, 2021, 8:13 AM Matt Sicker wrote:
> Website builds are handled by a specific deployment script that
> doesn't necessarily need to give write access to GitHub Actions or
> other builds. Unless you're talking about generating a static site and
> committing it to git and then having it
>
>
>
> Btw this is really not ideal if the action is docker based like the GitHub
> SuperLinter. Rebuilding this takes forever if it does not pull the
> existing container.
>
I belive super linter is an official GitHub one. All official actions that
are
GitHub owned are 'business as usual'. And
>
>
>
> If we ban persisted credentials in the checkout action it becomes very hard
> to commit the static website build. My example is what triggered this
> whole conversation about how they are persisted because this is how it
> works for us today, which I guess was not common knowledge.
>
This
On Wed, Jan 6, 2021, 8:39 AM Jarek Potiuk wrote:
> >
> >
> >
> > Btw this is really not ideal if the action is docker based like the
> GitHub
> > SuperLinter. Rebuilding this takes forever if it does not pull the
> > existing container.
> >
>
> I belive super linter is an official GitHub one. Al
>
>
>
> I am aware of how to use Docker in our build jobs... I am talking about
> Docker based GitHub Actions. They can have published docker
> images that they used so they do not get rebuilt all of the time. I called
> out SuperLinter as just an example.
>
Same thing. You can build and push D
12 matches
Mail list logo
