Use of reusable workflows for ci

[mcbarton]

Now that the ci in the repos are approximately the same, we are now in a position to start replacing it with reusable workflows from a central repo. @vgvassilev could you make a repo for these workflows, and then change the settings of that repo according to what is described in the below link

https://github.blog/2022-02-10-using-reusable-workflows-github-actions/

After this has been done I will begin the process of replacing parts of the ci in this repo (and others) bit by bit with the workflows in this new repo. That way the ci is all the repos should then stay upto date with each other.

[vgvassilev]

Can you propose a repo name?

[mcbarton]

Can you propose a repo name?

I'd just go with something simple like 'Reusable-Workflows' or 'Reusable-Actions' . That way its clear to anyone who clicks on the organisation what it contains.

[maximusron]

Looks cool! Does this allow us write to a single workflow for the CI that can be used as the main workflow for the three cppyy repo and as a subworkflow within InterOp? That would be amazing

[mcbarton]

Looks cool! Does this allow us write to a single workflow for the CI that can be used as the main workflow for the three cppyy repo and as a subworkflow within InterOp? That would be amazing

@maximusron You'll be able to write to worflows in this new repo, and all the repos will use it accordingly. There will be no need in future to update it in all the repos separately. The cppyy/CppInterOp repos will call the workflows from this new repo.

[maximusron]

Yep I understand that, my question was more about the way we pull these workflows and how we choose to discretize their parts. For example up until the Build and Test CppInterOp will differ in cppyy repos from the CppInterOp repos. The cppyy installation + testing will remain common. So we need to break it into reusable parts that make the most sense. For example

[mcbarton]

Yep I understand that, my question was more about the way we pull these workflows and how we choose to discretize their parts. For example up until the Build and Test CppInterOp will differ in cppyy repos from the CppInterOp repos. The cppyy installation + testing will remain common. So we need to break it into reusable parts that make the most sense. For example

@maximusron How you would like to see the workflow broken down into smaller chunks its probably more of a discussion for you and @vgvassilev to discuss (Alternatively I could also break it down into what I think are small useful chunks, and you can make suggestions for improvements as I do the transition). In the case where you want a Valgrind check, documentation, coverage, etc this can be done with workflow inputs. I'll try and implement the way you choose, and cc you if I run into any difficulties.

[vgvassilev]

Can you propose a repo name?

I'd just go with something simple like 'Reusable-Workflows' or 'Reusable-Actions' . That way its clear to anyone who clicks on the organisation what it contains.

Do we envision anybody else beyond our org to use these actions? If so, we need to have some sort of prefix?

[mcbarton]

Can you propose a repo name?

I'd just go with something simple like 'Reusable-Workflows' or 'Reusable-Actions' . That way its clear to anyone who clicks on the organisation what it contains.

Do we envision anybody else beyond our org to use these actions? If so, we need to have some sort of prefix?

@vgvassilev I could be wrong, but I don't believe anybody outside the organisation will be able to make use of this repo.

[mcbarton]

@vgvassilev This part of the link I put in the issue says you set it so it cannot be used outside the organisation.

[vgvassilev]

I meant if we expect the workflows to be generic enough so that somebody else outside of our org to find them useful and possibly use them.

[mcbarton]

I meant if we expect the workflows to be generic enough so that somebody else outside of our org to find them useful and possibly use them.

@vgvassilev There may be some workflows generic enough for others to use them (for example I can probably make the llvm cache one generic enough). I suspect the majority at least at first will specific to the organisation. I don't know what name to put for the repo in these circumstances.

[vgvassilev]

@mcbarton, https://github.com/compiler-research/ci-workflows

I've made you maintainer and you should be able to do almost everything.