verify and publish binaries generated by CI #229
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
saem
reviewed
Feb 11, 2022
| ## :triplet: | ||
| ## The triplet it is targeting | ||
| if file.len == 0: | ||
| raise newException(ValueError): |
There was a problem hiding this comment.
Future directional thought: We really should bring result/try into stdlib.
For maximum performance DOD land, the database should probably just have error storage that needs to be resolved and cleared prior to using it further -- not recommend here.
This is the final portion of continous delivery pipeline which creates a
release based on artifacts created during a CI run done as part of a
merge via bors.
The release created will contain a JSON manifest and release binaries.
The JSON manifest follows this schema:
```json
{
"manifestVersion": 0,
"version": "version identifier (ie. 0.1.0-dev.20000)",
"source": {
"name": "source-archive-name",
"sha256": "checksum"
},
"binaries": [
{
"target": "the target triplet (eg. x86_64-linux-gnu)",
"name": "binary-archive-name",
"sha256": "checksum"
}
]
}
```
This manifest allow tools to easily pick out the artifact that they need
depending on the target operating system, and it also prevent the need
to hard-code a specific file name format in such tools.
Coming in this commit is:
- A release manifest manipulation tool: This tool is used to create a
release manifest from archive manifests generated by niminst. At the
moment it does not have many features other than the ones required by
the pipeline. Refer to the tool built-in help for details on how to
use it.
- An additional test in main CI to verify that the release manifest tool
can create a release manifest from binaries generated there.
- Extra steps in publisher that download and create a release out of
artifacts created by main CI.
alaviss
force-pushed
the
publish-bin-upstream
branch
from
e179d54 to
354010a
Compare
|
We gunna get nightlies! 🎉 |
|
Build succeeded: |
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.
Summary
This is the final portion of continous delivery pipeline which creates a
release based on artifacts created during a CI run done as part of a
merge via bors.
The release created will contain a JSON manifest and release binaries.
The JSON manifest follows this schema:
{ "manifestVersion": 0, "version": "version identifier (ie. 0.1.0-dev.20000)", "source": { "name": "source-archive-name", "sha256": "checksum" }, "binaries": [ { "target": "the target triplet (eg. x86_64-linux-gnu)", "name": "binary-archive-name", "sha256": "checksum" } ] }This manifest allow tools to easily pick out the artifact that they need
depending on the target operating system, and it also prevent the need
to hard-code a specific file name format in such tools.
Details
This PR comes with:
A release manifest manipulation tool: This tool is used to create a
release manifest from archive manifests generated by niminst. At the
moment it does not have many features other than the ones required by
the pipeline. Refer to the tool built-in help for details on how to
use it.
An additional test in main CI to verify that the release manifest tool
can create a release manifest from binaries generated there.
Extra steps in publisher that download and create a release out of
artifacts created by main CI.
Notes for Reviewers
Currently it does not support automated creation of a non-development release. This will come later.
The release description is very plain at the moment. Suggestions on what to put in them would be appreciated.
This pipeline will create a release on the main repository, which makes it a bit scary as tags are not removable (they can, but should never be done).
A test release created by this pipeline can be found here: https://github.com/alaviss/nimskull/releases/tag/0.1.0-dev.20056