Cloud Native Computing Foundation Production Identity Day: SPIFFE + SPIRE 2020, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Making Your First Contribution to SPIRE (optional session) - Ryan Turner

Description

Making Your First Contribution to SPIRE (optional session) - Ryan Turner

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

A

Hey everyone uh yeah. So, as umer said, I'm brian turner, I'm a software engineer at uber and I've been a contributor in the spire project uh for a little over a year. Now, um so let's go ahead and get started um so great. You might be interested in making a contribution to spire for a variety of reasons and maybe you're just interested in the project and are eager to get your hands dirty and learn more about it and get deep into the code.

A

If so, that's great, and if you're kind of newer to the project, maybe a good place to start would be to look through the github issues and there's a tag. That's applied to some of the issues which is called community good first issue.

A

These are generally kind of the low-hanging fruit work that needs to be done in the project. You can think of things like test improvements or refactoring or maybe minor documentation updates those kinds of things that don't require a lot of expertise and anything in any of the code in the project.

A

Another scenario is, you might be looking to use spire or maybe you're already deploying spire and you've identified some issues, or some lack of feature. Support for a specific use case that you have in your organization.

A

A great place to start is to look through the github issues and see if anybody has reported this issue in the past and if not, I would highly recommend that you go ahead and create an issue and just in the issue, just kind of give a brief summary of what it is that you're facing. Or you know what kind of issue you've seen. That's something that maintainers the projects actively monitor every week. um So we, the maintainers, try to get back to uh folks who create issues in a pretty short time.

A

So and if you are just certain uh unsure about whether spire works in a certain mode or um whether there is support for a specific kind of environment, a good place to start might be in the spiffy slack workspace.

A

There's a dedicated channel spire, which is you know, includes people from the community includes the maintainers, the project and the maintainers pretty actively watch that channel. So that's a great place to kind of get started as well.

A

So, let's say you've kind of figured out an issue that you want to run with and actually make a contribution.

A

So the best place to start here is to go to this contributing markdown file, which is at the root of the spire repository in github uh and this contributing dock. I think I'll just go ahead and jump to it be more useful to just look at it directly.

A

So here is the spire repository in github, and if we go down a bit here, there's this contributing.md I'll click into that.

A

And so a few things you want to kind of look through here. One is just sort of the general contributing and governance guidelines that are established throughout the spiffy projects.

A

Once you kind of review those this is some prereqs for getting your dev environment set up for perspire, um so you'll have to go through that um this describes kind of how you build the project, how you run tests, how you run and build docker images um that you can use to test locally.

A

There are also some conventions explained here throughout the project of you know where code lives, so there's been quite a bit of code. That's been added to spire in the past couple years, so if you're kind of newer to the code base, this is a good place to start to see how things are laid out. So you can find the particular module or subsystem that you're looking to modify or extend and then there's a lot of conventions that are established at the project, uh just naming conventions, metric name conventions and how metrics are emitted.

A

um There's also some logging and error conventions, uh just how capitalization of messages and things like that and a little bit of talk about how mocks are used in the project, and so this is kind of like the overall landing page for getting started.

A

Once you've actually submitted a contribution locally in a commit, then you can submit a pull request for that and the pull request will just have a template. I can pull up a pull request. I have open right now just to show an example.

A

um So when you push your branch to your remote fork and generate this pull request, you'll get this template. It includes this checklist of. Does this commit conform to the contributing guidelines? Does it include the proper tests and regression tests and is any documentation updated that needs to be updated? um If this feature does not have any forward-facing documentation, then this could be optional.

A

uh You'll just want to kind of talk about what is the affected functionality and your change and then an overall description of what the changes and then uh the maintainers of the project are automatically included in the reviews. uh So uh this is something maintainers monitor every week and try to give timely feedback on.

A

So I think we're running a little bit over time, so I'll go ahead and stop there. If you have any questions, feel free to send them my way or to the spiffy slack we'd be happy to answer this thanks.