-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
CI (Buildkite): upload musl64 nightly binaries to S3 #42495
Conversation
e281fd0
to
b36a125
Compare
b36a125
to
f4cf448
Compare
- pipeline: .buildkite/pipelines/main/upload_s3/musl.yml | ||
signature_file: .buildkite/pipelines/main/upload_s3/musl.yml.signature |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of adding this to 0_webui.yml
, which is somewhat disruptive, as you have seen, we should instead launch a signed_pipelines.yml
which serves as a launchpad for our signed pipelines, just like how we have a launch_unsigned_builders.yml
. This minimizes the amount of changes to 0_webui.yml
that we have to perform.
When we do need to change 0_webui.yml
, what we should do is test it out with the experimental pipeline, then add all the files we need, let it sit on master
for a week, then add it to the 0_webui.yml
file. This will give our changes a chance to propagate to most of the PRs that are being opened at the time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is the idea that 0_webui.yml
(and the contents of the web UI) will look like this:
# This file represents what is put into the webUI.
# It is purely for keeping track of the changes we make to the webUI configuration; modifying this file has no effect.
# We use the `cryptic` buildkite plugin to provide secrets management, which requires some integration into the WebUI's steps.
agents:
queue: "julia"
sandbox.jl: "true"
steps:
- label: ":unlock: Unlock secrets, launch pipelines"
plugins:
- staticfloat/cryptic:
# Our list of pipelines that should be launched (but don't require a signature)
# These pipelines can be modified by any contributor and CI will still run.
# Build secrets will not be available in these pipelines (or their children)
# but some of our signed pipelines can wait upon the completion of these unsigned
# pipelines.
unsigned_pipelines:
- .buildkite/pipelines/main/launch_unsigned_builders.yml
# Our signed pipelines must have a `signature` or `signature_file` parameter that
# verifies the treehash of the pipeline itself and the inputs listed in `inputs`
signed_pipelines:
- pipeline: .buildkite/pipelines/main/signed_builders.yml
signature_file: .buildkite/pipelines/main/signed_builders.yml.signature
And then the .buildkite/pipelines/main/signed_pipelines.yml
file looks like this:
agents:
queue: "julia"
sandbox.jl: "true"
steps:
- label: "Signed pipelines"
plugins:
- staticfloat/cryptic:
# Our signed pipelines must have a `signature` or `signature_file` parameter that
# verifies the treehash of the pipeline itself and the inputs listed in `inputs`
signed_pipelines:
- pipeline: .buildkite/pipelines/main/misc/signed_pipeline_test.yml
signature_file: .buildkite/pipelines/main/misc/signed_pipeline_test.yml.signature
- pipeline: .buildkite/pipelines/main/upload_s3/musl.yml
signature_file: .buildkite/pipelines/main/upload_s3/musl.yml.signature
Is this correct?
We will continue working on this in the https://github.com/JuliaCI/julia-buildkite repository. |
No description provided.