Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

workflows: add 1.8 branch container build #6189

Merged
merged 1 commit into from
Oct 21, 2022

Conversation

patrick-stephens
Copy link
Contributor

Signed-off-by: Patrick Stephens pat@calyptia.com

After removal of 1.8 build support, this re-introduces a separate workflow to provide a container build for a 1.8 based branch.


Enter [N/A] in the box, if an item is not applicable to your change.

Testing
Before we can approve your change; please submit the following in a comment:

  • Example configuration file for the change
  • Debug log output from testing the change
  • Attached Valgrind output that shows no leaks or memory corruption was found

If this is a change to packaging of containers or native binaries then please confirm it works for all targets.

Documentation

  • Documentation required for this feature

Backporting

  • Backport to latest stable release.

Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

Signed-off-by: Patrick Stephens <pat@calyptia.com>
@edsiper
Copy link
Member

edsiper commented Oct 15, 2022

why master and not 1.8 branch ? (just curious)

@patrick-stephens
Copy link
Contributor Author

why master and not 1.8 branch ? (just curious)

There's no real technical reason, just a philosophical one.

Primarily for simplicity: we have a single source of truth rather than having to merge/duplicate every change across them plus figuring out which workflows should fire (e.g. for PRs) is more straightforward. Initially as well I did not want to touch the workflows for the old branch (1.8) when I started so it made a nice separation.

It also means you do not have to remember to run the workflow on the right branch and we can instigate some protection via environments (e.g. you can only release from a master workflow).

@patrick-stephens
Copy link
Contributor Author

There are some other issues as well with using the non-default branch: https://devopsjournal.io/blog/2022/08/12/workflows-not-starting

@edsiper @lecaros : in this case we want a new workflow to be available as a manual trigger so it must be on the default branch at least to enable the workflow (even if you then target another branch) - we could then also merge it to 1.8 but that seems pointless when we can do the build regardless.

@lecaros
Copy link
Contributor

lecaros commented Oct 18, 2022

Great explanation. Thanks @patrick-stephens!

@lecaros
Copy link
Contributor

lecaros commented Oct 20, 2022

can we merge this?

@niedbalski niedbalski merged commit 1fc1e81 into master Oct 21, 2022
@niedbalski niedbalski deleted the add_container_1_8_build_workflow branch October 21, 2022 08:32
@lecaros
Copy link
Contributor

lecaros commented Oct 21, 2022

thanks!

mgeriesa pushed a commit to mgeriesa/fluent-bit that referenced this pull request Oct 25, 2022
Signed-off-by: Patrick Stephens <pat@calyptia.com>

Signed-off-by: Patrick Stephens <pat@calyptia.com>
Signed-off-by: Manal Geries <mgeriesa@gmail.com>
sumitd2 pushed a commit to sumitd2/fluent-bit that referenced this pull request Feb 8, 2023
Signed-off-by: Patrick Stephens <pat@calyptia.com>

Signed-off-by: Patrick Stephens <pat@calyptia.com>
Signed-off-by: root <root@sumit-acs.novalocal>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants