Extend NRP build workflow to support creating/updating Github releases with artifacts #797
Conversation
| sed -e "s|@HASH@|${ssh_hash}|g" -e "s|@URI@|${ssh_uri}|g" ${ssh_template} > ${ssh_output} | ||
|
|
||
| - name: Create or update release with new artifacts | ||
| uses: softprops/action-gh-release@v2 |
There was a problem hiding this comment.
@v2 is mutable AFAIK. I would opt for freezing it with a commit hash for security reasons.
There was a problem hiding this comment.
Hmm, in the past i considered this overkill, it would need to be done for all actions and we'd likely forget to keep them updated.
I'm interested in hearing more perspectives on this.
There was a problem hiding this comment.
What I mean is: the attack vectors are supply chain attacks on the one hand and outdated vulnerable dependencies on the other. Dependabot might be able to help.
There was a problem hiding this comment.
I love everything being hermetic and having an automated way of creating PR with bumped up dependencies for just a manual reviews.
It minimizes flakiness and maintains source code governance so positively impacts security.
I'm not going to insist here ofc. We don't have such automations here yet.
There was a problem hiding this comment.
In the past we have used gh release create to automate the release creation on GitHub as part of a script after the "official" GitHub release action is no longer maintained (and to avoid using 3rd party actions for publishing releases which could result in supply chain as you mentioned).
https://cli.github.com/manual/gh_release_create
For prerelease this seems fine to me though, we can revisit it later for official releases as needed.
There was a problem hiding this comment.
+1 on using gh cli, i prefer that over 3p actions (albeit being mentioned on the official https://github.com/actions/create-release action) but wont block on it
There was a problem hiding this comment.
I'll give it a try (hopefully next week).
jepio
force-pushed
the
publish-nrp-artifacts
branch
from
563a2d7
to
ec23951
Compare
Good idea, did this just now. |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
…tifacts Signed-off-by: Jeremi Piotrowski <[email protected]>
jepio
force-pushed
the
publish-nrp-artifacts
branch
from
ec23951
to
4336d6a
Compare
|
I've reverted the static policy json files, keeping those does not interfere with the purpose of this PR (nor does this PR interfere with other usecases). I need some more time to respond to the comments. |
Description
Currently test NRP artifacts are published to Github releases manually, and the policy json is separately committed to main here: https://github.com/Azure/azure-osconfig/blob/main/src/adapters/mc/asb/AzureLinuxBaseline_DeployIfNotExists.json (ditto for ssh policy). This manual process is error-prone and the two artifacts (zip+policy json) regularly get out of sync. This has led to confusion among team members trying to test recent releases.
Improve the situation by extending the NRP build workflow to support automatically creating a Github release with all the relevant artifacts: zip files and matching policy json. The policy json template is filled with the correct checksum and URL to the release being published. The body of the release will now contain a reference to the commit that the policy was built from for easy cross-referencing.
Passing an empty string for "release name" will result in no Github release being created. An existing "release name" can be passed which will update artifacts and body of that release.
The static policy.json files (non templates) have been removed as they will no longer need to be kept in sync.
Checklist
mainbranch prior to this PR submission.mainbranch.