build - build with the correct security context #1764
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Erwinvandervalk
added
area/all
damianh
reviewed
Feb 5, 2025
damianh
reviewed
Feb 5, 2025
Erwinvandervalk
force-pushed
the
ev/build
branch
from
1be3472 to
59809bb
Compare
damianh
approved these changes
Feb 5, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What issue does this PR address?
This PR changes the build so that a build runs only once, and in the right security context, depending on their origins.
Previously, the build used pull_request_target. Effectively, this means that the entire context (including which code to build) was pointing to the target of the PR (likely main). This means it wasn't building anything in the PR, but actually building main (not very useful in a PR workflow)
How does it work?
Builds / pr's from contributors are run trusted and can access security tokens needed for signing. If you create a branch in the DuendeSoftware repo, then you'll automatically get a CI build for this. You can (must) create a PR for this to get it merged. When you create a PR, the build script will detect that there is still a branch for it and will built it normally (skip the PR build).
Builds from PR's created from external contributors (which have to originate from a different fork) will NOT run with security tokens, so artifacts will not be signed / pushed.
Publishing artifacts somewhere from external contributors.
/
If we ever want to to anything with the output of external pr's other than merge them into main (IE: deploy them somewhere), then we should:
a. let the build publish the artifacts to github.
b. setup a different workflow that will run only if the after the previous build is complete AND if pr is labelled (which only contributors can do) This workflow can then publish the changes.
Important: Any code or remarks in your Pull Request are under the following terms:
If You provide us with any comments, bug reports, feedback, enhancements, or modifications proposed or suggested by You for the Software, such Feedback is provided on a non-confidential basis (notwithstanding any notice to the contrary You may include in any accompanying communication), and Licensor shall have the right to use such Feedback at its discretion, including, but not limited to the incorporation of such suggested changes into the Software. You hereby grant Licensor a perpetual, irrevocable, transferable, sublicensable, nonexclusive license under all rights necessary to incorporate and use your Feedback for any purpose, including to make and sell any products and services.
(see our license, section 7)