Makefile: add a cross target 🌵 #2903
Conversation
This will allow building for different target (x86_64, arm, arm64, s390x and ppc64le). This doesn't mean we support those architecture (especially as `ko` doesn't really support multi-arch for now). But it is nice to be able to see if our code compiles and can be package (manually, *unofficially*, for those target). A check will be added in plumbing so that we validate that, at least, a PR doesn't break those. Signed-off-by: Vincent Demeester <[email protected]>
|
@vdemeester: GitHub didn't allow me to request PR reviews from the following users: snehlatamohite. Note that only tektoncd members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
tekton-robot
added
release-note
|
This PR cannot be merged: expecting exactly one kind/ label Available
|
2 similar comments
|
This PR cannot be merged: expecting exactly one kind/ label Available
|
|
This PR cannot be merged: expecting exactly one kind/ label Available
|
|
/kind misc |
|
I'm a bit confused about where we'd draw the line between the makefile and Task with params. I'd imagine we'd have a build Task that takes params that prompt it to build differently, vs. a Task that calls make, what are your thoughts? |
@bobcatfish by Task I guess you mean a Tekton Task right ? The Task exists already, it is the
|
yep that's right!
@vdemeester how would you see this working once we DO use Tekton for our CI here, would we have a Task that calls the Makefile, or would we duplicate the logic between using the golang-build Task and the Makefile? (or something else?) |
Whatever works. Overall, I see the |
|
It sounds like it depends on whether or not it's possible to run Tasks locally - if you could easily run Tasks locally, I think you'd be into using Tasks all the way instead of a Makefile, is that right? I really do think it's important that we find a way to make Tasks run locally ( #235 ), otherwise folks will experience frustrating with invoking different CI when they are developing vs. when they submit (or maybe I should re-state as: we have an opportunity to really improve this experience by making these two workflows the same! :D) |
It depends too 😝. How much do I need to write for using Tasks vs Makefile ? What do I prefer to do as my developer inner-loop workflow, … ? How much do I buy into the outer loop — aka do I want the CI to drive my local dev experience (or the opposite) ?
I see value on adding a way to run Tasks locally for sure but I don't see it as extremely important (at least for now, in the current state of tekton components). Mainly because fixing the "frustration with invoking different CI when they are developing vs. when they submit" is something that can be fixed outside of tekton scope — it's an organizational problem, you can make |
I guess it depends on the unit that you are using for this kind of sharing organizationally: you could have everyone in your org using the same Makefile, or the same Task, or you could have them all using the same bash script. I feel like one of the things Tekton is attempting to solve is providing the standardization mechanism and making that a Task. If you use Makefiles as your standardization mechanism, we'd really only need one Task: the makefile Task. I also see a lot of parallels between Tasks + Pipelines and Makefiles, they feel to me like they are trying to solve a lot of the same problems, so I have trouble seeing the line between the two, similarly to the line between a Task that calls a bash script which takes a bunch of args to determine what to do. In both cases I'd like to see more of the logic moved up into the Tasks and Pipelines, and less happening in the things they invoke. |
By organizational problem I didn't mean it as at the level of an organization (a company, a project, …), but on the way you want to handle inner and outer loop ; and how developer organize themselves. For example, even if you provide a
From the website :
From the
It's not yet our "goal" to provide a standard mechanism for anything else than CI/CD systems (aka local dev, inner loop). It could be at some point, it's not the case now. Tekton bring the portability of containers in the CI/CD world on top of k8s in a nice and easy way for the user (at least that's the goal 👼). It doesn't
I don't see a lot of parallels between Tasks + Pipelines and Makefiles. From the GNU Make website:
In a long-term ideal world, you would to a |
|
It sounds to me like it would be good to get more clear on this inner loop vs. outer loop distinction because that sounds quite different from how I look at things. Ideally I'd like to be running the same thing as part of my development workflow as is used as part of the automated CI systems - this whole "shift left" thing is above getting signals earlier, and what better time to get signals than as you work. If you can run the same thing locally easily that you run remotely, then great! Maybe we should create another issue and/or doc where we can talk about this distinction?
What I'd want here is a way to be able to go from a Task to the containers run inside the task to the commands run inside the container. I don't want to be doing something totally different from what the CI is doing, I want to know what the CI is doing and customize it.
What I mean is when people use Makefiles as the interface to building + testing their projects. I think a lot of projects have Makefiles that provide interfaces like The Makefile then is the interface to the CI behaviors (testing, linting, building) and is also the place where the logic that defines those behaviors is stored. If Tekton Tasks are used as a wrapper around calling make files and scripts, I think we've lost a lot of the power. |
Maybe (especially as we are discussing something far from what that PR does initially, which is add a few target to an existing
Sure that is the ideal world, the ultimate idea. We had some discussion at docker around this: That's a general ideal idea for sure, and it would be nice to have at some point but, there is also pragmatism and how user are doing things now and how we can help them. And also, again, what is the goal of tekton ? I don't think it is to be as involved as this in the dev workflow — or we need to update it.
How so ? What is "power" here even ? What is Tekton trying to solve ? How should it impact the way user and team develop locally and what tool they are using for this ? In any case, does this (above) prevents from this PR to get reviewed and merged ? 😛 🙃 |
|
Okay I've started tektoncd/community#145 to take the local development workflow discussion out of this PR
Considering that we've already got the Makefile, I don't think any of my thoughts here would block this PR - I do wonder about the Makefile in general but not to block this PR. Last question about the Makefile:
I think I'm a bit confused b/c this particular Makefile I think exists so Prow can call it, and not (if I understand) to facilitate the "inner loop" of local development. Would that mean this particular Makefile is a temporary measure until we have migrated from Prow to Tekton? |
Nope, prow doesn't use the |
Right but the intention is for prow to run it right? I'm still a bit confused.
Maybe we should mention it at https://github.com/tektoncd/pipeline/blob/master/DEVELOPMENT.md then? |
Nope 😛. The intention is really to simplify my (my being "me the contributor") life when in the inner loop. I can run whatever the
Indeed, we should probably mention it there. I can prepare a PR for this 😉 |
Ah kk I think I'm starting to understand - my preference would be that we do add any tools we're giving to maintainers to our automation. Otherwise we'll be in a situation where say maybe only you are ever running this Makefile, or maybe you stop one day, does it keep working over time, do we expect people to be running it - all of this is kind of ambiguous unless we're invoking the tool/Makefile in our automation. |
|
Perhaps before merging this we should add some docs to clarify that:
|
As we don't document the makefile anywhere, that's a given, but yeah we can document that (or document which architecture we support).
The makefile is merely a convenience setup for the |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: afrittoli The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
tekton-robot
added
the
approved
Changes
This will allow building for different target (x86_64, arm, arm64,
s390x and ppc64le).
This doesn't mean we support those architecture (especially as
kodoesn't really support multi-arch for now). But it is nice to be able
to see if our code compiles and can be package (manually,
unofficially, for those target). A check will be added in plumbing
so that we validate that, at least, a PR doesn't break those.
Signed-off-by: Vincent Demeester [email protected]
/cc @snehlatamohite
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Double check this list of stuff that's easy to miss:
cmddir, please updatethe release Task to build and release this image.
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes