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

ci: add mcs-export workflow #499

Closed
wants to merge 1 commit into from
Closed

Conversation

mbrcknl
Copy link
Member

@mbrcknl mbrcknl commented Jul 7, 2022

This adds adds an mcs-export workflow, as a further step towards solving
issue #497. This replaces the mcs-export matrix job that was removed
from the proof-deploy workflow in #498.

This workflow has some similarities to the proof-deploy workflow:

  • Both workflows check out a manifest, run some proofs, and trigger
    a binary verification workflow.
  • Both workflows are triggered by an update to an l4v branch.
  • Both workflows can be triggered by manual updates to the development
    verification-manifest, but not automatic updates due to a successful
    preprocess test.

The differences are:

  • proof-deploy updates the default verification-manifest, whereas the
    mcs-export workflow does not.
  • proof-deploy uses l4v master, whereas mcs-export uses the rt branch.

When MCS CRefine proofs are sufficiently advanced, the proof-deploy
workflow will need to be updated to check MCS proofs before updating the
default verification-manifest. At that point, this workflow could be
reintegrated into the proof-deploy workflow.

Signed-off-by: Matthew Brecknell matt@kry10.com

This adds adds an mcs-export workflow, as a further step towards solving
issue #497. This replaces the mcs-export matrix job that was removed
from the proof-deploy workflow in #498.

This workflow has some similarities to the proof-deploy workflow:
- Both workflows check out a manifest, run some proofs, and trigger
  a binary verification workflow.
- Both workflows are triggered by an update to an l4v branch.
- Both workflows can be triggered by manual updates to the development
  verification-manifest, but not automatic updates due to a successful
  preprocess test.

The differences are:
- proof-deploy updates the default verification-manifest, whereas the
  mcs-export workflow does not.
- proof-deploy uses l4v master, whereas mcs-export uses the rt branch.

When MCS CRefine proofs are sufficiently advanced, the proof-deploy
workflow will need to be updated to check MCS proofs before updating the
default verification-manifest. At that point, this workflow could be
reintegrated into the proof-deploy workflow.

Signed-off-by: Matthew Brecknell <matt@kry10.com>
@mbrcknl mbrcknl added CI continuous integration and testing MCS related to `rt` branch and mixed-criticality systems BV related to Binary Verification labels Jul 7, 2022
@mbrcknl mbrcknl requested a review from lsf37 July 7, 2022 07:06
@mbrcknl mbrcknl marked this pull request as draft July 7, 2022 08:17
@mbrcknl
Copy link
Member Author

mbrcknl commented Jul 7, 2022

Switched to draft while thinking about #497.

@mbrcknl
Copy link
Member Author

mbrcknl commented Dec 5, 2022

Closing for now. Will make new PRs when I have a better solution for #497.

@mbrcknl mbrcknl closed this Dec 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BV related to Binary Verification CI continuous integration and testing MCS related to `rt` branch and mixed-criticality systems
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant