Git Product home page Git Product logo

flatcar-build-scripts's Introduction

Flatcar Container Linux

Mission statement

Flatcar Container Linux is a fully open source, minimal-footprint, secure by default and always up-to-date Linux distribution for running containers at scale.

Code of Conduct

We follow the CNCF Code of Conduct.

Please contact private Maintainer mailing list or the Linux Foundation mediator, Mishi Choudhary [email protected] to report an issue.

Releases

See the project website for information about current releases.

Install and operate Flatcar

Flatcar Container Linux has a dedicated documentation site.

The getting started guide has further links to the topics Ignition, local testing with QEMU, controlling automatic updates, and usage with cloud providers:

Does Flatcar run in my environment? Consult the interop-matrix.

Does Flatcar have CIS Benchmarks? Consult the CIS reports.

Report bugs and request features

If you hit a bug, or have a feature request, please file an issue right here in this github project. Please select the appropriate issue type to help us triage incoming requests. For example, if you would like a new package to be added to the base Flatcar image, use the "New Package Request" issue type. (In that specific case, please also see adding new packages to the Flatcar Linux OS image for general guidelines.)

Chat

For quick questions or for just hanging out with the community please use

Discussions

For more far-reaching topics please have a look at our discussions. Feel free to open a new discussion if you don't find an existing one covering your topic.

Mailing lists

Though the use of Github Discussions is encouraged (see above), we also maintain groups / mailing lists for a more old-fashioned way of having a discussion. Please note that we might consider to discontinue these mailing lists at some point in the future.

Social Media/Fediverse

You can follow the Flatcar Mastodon account. While Mastodon, as an open platform, is our preferred social media channel, we also have an account on X.

Participate and contribute

If you are thinking of making a contribution, then please engage with the project as early as possible -- by commenting on an existing issue, or creating a new issue, on GitHub. Consider the project’s mission, and how your contribution furthers it. Making your intent visible early on can be a major factor for getting your work accepted.

For the general guidelines on making PRs/commits easier to review, please check out the project's contribution guidelines.

For an introduction to the Flatcar SDK and a walk-through of common developer cases like customising the OS image (e.g. adding or upgrading packages), have a look at our developer guides; particularly the howto on building custom images from source. The guides aim to provide a solid base for working with the SDK to help you filing successful PRs to the Flatcar project.

Becoming a maintainer

The Flatcar maintainer path is laid out in our governance document.

Project status and roadmap - What's everybody working on, right now and in the future?

  1. short-term concerns (bugs and minor enhancements) enter the project via our issue tracker
  2. our tactical board reflects the issues and PRs the maintainers and the contributors are currently engaged with
  3. items which are done will be assigned to an upcoming release on the release board in our release planning calls

Lastly, epics like major features and long-term items are reflected in our roadmap board.

Check out our Matrix and Slack channels (mentioned above) for getting into contact with maintainers, and consider joining our Flatcar Developer Sync (next section below) where contributors and maintainers coordinate our work.

Monthly Office hours and Developer Syncs

We maintain a Google Calendar (iCal) with both our Office Hours and Developer Sync meeting series which interested folks can comfortably import into the calendar app of their choice.

Join us in our monthly office hours meetings to engage with the Flatcar User community interactively, to learn about the project's directions, and to discuss contributions. We also conduct the occasional user-focused demo of technologies related to image-based Linux. Lastly, the call includes a brief Release Planning with an update on the changes in the next immediate releases.

If you'd like to share something or if you have a pressing issue you'd like discussed, please let us know. Either comment on the respective meeting discussion, reach out to us on Matrix (see below), or simply join the meeting and speak up in the meeting's Q&A.

Flatcar Office Hours are on the second Wednesday of every month at 2:30pm UTC

Flatcar Developer Syncs commence every 4th Wednesday of a month at 2:30pm UTC

While release planning is a recurring part of each community call we also conduct separate Developer Syncs for backlog grooming and task planning. We discuss Roadmap items, special projects, and day-to-day issues in these calls. If you want to participate and discuss or pick up work, that call is for you! Just like the Office Hours the call includes a brief Release Planning with an update on the changes in the next immediate releases.

Release process

Flatcar Container Linux follows an Alpha-Beta-Stable release process. New features and major version upgrades will enter the Alpha channel for initial testing, then transition to Beta, before landing in Stable.

Note that unlike features, bug fixes for any release channel will be released to that respective channel directly, i.e. Alpha bug fixes will be included in the next Alpha, Beta fixes will directly go to Beta, and Stable fixes will be released with the next Stable.

We plan our releases in a 14-day cadence. The maintainer team holds fortnightly release meetings - both as recurring part of our monthly community calls as well as a separate meeting in-between the monthly community call cadence. Up-to-date planning status is reflected in our release planning board.

LTS

Some users prefer to avoid the operational impact of frequent version upgrades. For such users, the Flatcar project provides an "LTS channel". The LTS channel / branch is based on a "golden Stable" and is maintained for 18 months. A new LTS is branched from Stable every 12 months, leaving a 6 months window for LTS users to upgrade.

Project governance

Flatcar is a community-driven project, with community members participating through the following forums:

  • Contributors.
  • Maintainers.

Every participant of the open source project - bug reporter, feature requester, code contributor - is considered a contributor.

Maintainers have commit access to one or more repositories and help govern the project, driving it forward and maintaining its scope and vision. Please find more details in our governance doc.

Repositories

The github repositories that comprise Flatcar Container Linux can be found via the organization page.

flatcar-build-scripts's People

Contributors

chewi avatar dongsupark avatar iaguis avatar jepio avatar krnowak avatar margamanterola avatar pothos avatar sayanchowdhury avatar schu avatar t-lo avatar tormath1 avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

flatcar-build-scripts's Issues

rewrite apply-flatcar-patches using another language

This issue is a follow-up to this comment: #2 (comment)

We already implemented apply-flatcar-patches in bash, which works fine. However, it's not ideal at all to write such a comprehensive tool in bash. We need to rewrite this script in another programming language, for example in Go, to avoid writing further hacks on top of that.

A very simple example of synchronizing git repos is https://github.com/kubernetes/git-sync, but that's a way too simple tool in contrast to our requirements.

Another approach would be to make use of a native Go library for accessing to git repos, for example https://github.com/src-d/go-git. That way we can simply rely on a native XML parsing library in Go, as well as native slices and maps instead of hacks written in bash. Downside of using go-git is that the library is still not complete, for example git rev-parse is not implemented yet. So it might be still necessary to call external commands.

Print correct URL for pull requests in an other GitHub organization

For pull requests that were done in upstream repositories, the wrong PR link is printed because the flatcar-linux organization is used by default:
https://github.com/kinvolk/flatcar-build-scripts/blob/1adc2ce106c34465e14d9600f2295e151bca292d/coreos-overlay-diff.py#L81
Through some heuristic based on the merge commit we can try to resolve https://github.com/coreos/systemd/pull/XY or https://github.com/systemd-stable/systemd/pull/XY instead of https://github.com/flatcar-linux/systemd/pull/XY

coreos-overlay-diff.py is broken with Python sh 2.x

Description

This script was written against sh 1.x. There were some significant breaking changes in 2.x, notably the way pipes are constructed and the type returned.

Impact

Environment and steps to reproduce

  1. Set-up: I was running vanilla Gentoo with the latest dev-python/sh. Fedora 39 and 40 also have 2.x.
  2. Task: Simply running coreos-overlay-diff.py.
  3. Action(s): As above.
  4. Error: After the diff, you get an error like this:
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑ Diff for flatcar-overlay ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

Traceback (most recent call last):
  File "/home/chewi/Projects/flatcar/flatcar-build-scripts/./coreos-overlay-diff.py", line 190, in <module>
    display_difference(args.THEIRS, args.ours, os.path.basename(os.path.abspath(".")), recurse=True)
  File "/home/chewi/Projects/flatcar/flatcar-build-scripts/./coreos-overlay-diff.py", line 109, in display_difference
    commits_we_have = commits_to_pick(src=to_ours, dst=from_theirs)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/chewi/Projects/flatcar/flatcar-build-scripts/./coreos-overlay-diff.py", line 58, in commits_to_pick
    _commits_src_has_without_cherry = cut(grep(git.cherry(dst, src, _bg=False),
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/sh.py", line 1508, in __call__
    rc = self.__class__.RunningCommandCls(cmd, call_args, stdin, stdout, stderr)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/sh.py", line 737, in __init__
    self.wait()
  File "/usr/lib/python3.12/site-packages/sh.py", line 799, in wait
    self.handle_command_exit_code(exit_code)
  File "/usr/lib/python3.12/site-packages/sh.py", line 826, in handle_command_exit_code
    raise exc
sh.ErrorReturnCode_2: 

  RAN: /usr/bin/grep '+ 6cd2151eab1e0ff4834b94f250c9a78b0d29ca0e
+ fb79dad6fd97054290620943ea0bcb6b69a98137
+ 7e0a4836796bd5986697a9f27dccaff25f0ba787
+ e3903f11930d9c04f4cf4c047cf2c794aca9ac19
+ 6045acb9720b3bfc4f1f0c77907011e8abf25907
+ 06fa6b4913afbfcc72cccfdee94941aaf0034865
' '^+'

  STDOUT:


  STDERR:
/usr/bin/grep: ^+: No such file or directory

Expected behavior

It outputs information about which commits to pick.

Additional information

I would fix this now, but I imagine it's still used in places that don't have sh 2.x. We could support both, but quite a few lines would need to be duplicated. The syntax is quite different.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.