-
-
Notifications
You must be signed in to change notification settings - Fork 130
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
Add package workflow #491
base: develop
Are you sure you want to change the base?
Add package workflow #491
Conversation
.github/workflows/build_and_test.yml
Outdated
@@ -204,3 +204,37 @@ jobs: | |||
name: ${{ runner.os }}-Unit-Tests | |||
path: Test*.xml | |||
if: ${{ always() }} | |||
|
|||
package: | |||
name: Package |
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.
I don't think Package
is needed in the "CI" part of the pipeline.
We don't need to generate the package every time someone pushes a new commit to a PR.
And Package
is also defined (currently double) in the package_deploy.yml
-- where I think it actually belongs in.
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.
Correct. I was originally thinking of having every PR generate a package as well, but this is overkill.
Will cleanup before converting this Draft PR to a real PR.
.github/workflows/package_deploy.yml
Outdated
push: | ||
branches: | ||
- feature/package-artifact | ||
workflow_dispatch: |
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.
this is cool!
but does it need the :
?
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch
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.
I've always had it, I guess it's a force of habit. It's also how Copilot suggested it. 🤷♂️
.github/workflows/package_deploy.yml
Outdated
shell: pwsh | ||
run: | | ||
./Tools/setup.ps1 | ||
Invoke-Build -Task ShowInfo |
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.
consider removing this, if we don't need it.
I added this back in the day because the information was important to debug failed builds
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.
I find it useful and doesn't impact negatively the process. But your call.
.github/workflows/package_deploy.yml
Outdated
- name: Package | ||
shell: pwsh | ||
run: | | ||
Invoke-Build -Task Package |
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.
can't we inline this with the previous task?
Invoke-Build -Task Clean, Build, Package
it's not like the tasks would benefit from the split, right?
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.
Keeping the steps separate means it's easy to see quickly where it failed and why.
Not benefit to merging them together IMO. But you're call.
.github/workflows/package_deploy.yml
Outdated
run: | | ||
Invoke-Build -Task Package | ||
- name: Upload Artifact | ||
uses: actions/upload-artifact@v3 |
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.
Can we add if-no-files-found: error
(default is warning")?
https://github.com/actions/upload-artifact#customization-if-no-files-are-found
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.
The package step is 'new', it's so we can generate the zip file for the module. I'm not sure yet if it's even worth keeping once we add the release mechanism to GitHub. But will make the changes. Good for it to fail if not found.
|
||
$Prerelease = '' | ||
if ("$env:BHBranchName" -notin @('master','main')) { | ||
$Prerelease = "$env:BHBranchName".ToLower() -replace '[^a-zA-Z0-9]' |
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.
I would like more documentation on this.
I would expect $Prerelease
to be empty or -eq "alpha"
. But I don't know how you would name branches to get to that value
- Prerelease string may only be specified when the ModuleVersion is 3 segments for Major.Minor.Build. This aligns with SemVer v1.0.0.
- A hyphen is the delimiter between the Build number and the Prerelease string. A hyphen may be included in the Prerelease string as the first character, only.
- The Prerelease string may contain only ASCII alphanumerics [0-9A-Za-z-]. It is a best practice to begin the Prerelease string with an alpha character, as it will be easier to identify that this is a prerelease version when scanning a list of packages.
- Only SemVer v1.0.0 prerelease strings are supported at this time. Prerelease string must not contain either period or + [.+], which are allowed in SemVer 2.0.
- Examples of supported Prerelease string are: -alpha, -alpha1, -BETA, -update20171020
|
||
$Prerelease = '' | ||
if ("$env:BHBranchName" -notin @('master','main')) { | ||
$Prerelease = "$env:BHBranchName".ToLower() -replace '[^a-zA-Z0-9]' |
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.
the quotations around the $env:
are not needed
JiraPS.build.ps1
Outdated
@@ -194,6 +194,13 @@ task UpdateManifest GetNextVersion, { | |||
if ($ModuleAlias) { | |||
BuildHelpers\Update-Metadata -Path "$env:BHBuildOutput/$env:BHProjectName/$env:BHProjectName.psd1" -PropertyName AliasesToExport -Value @($ModuleAlias.Name) | |||
} | |||
|
|||
$Prerelease = '' | |||
if ("$env:BHBranchName" -notin @('master','main')) { |
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.
if you are checking the branch for both master
and main
-- which I am not opposed to -- should we use both values in the workflows too? (.github/workflows/build_and_test.yml#6)
.github/workflows/package_deploy.yml
Outdated
- name: Upload Artifact | ||
uses: actions/upload-artifact@v3 | ||
with: | ||
name: JiraPS.zip |
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.
https://github.com/actions/upload-artifact#zip-archives
The uploading of an artifact creates a .zip
for the upload.
So our build artefact is JiraPS.zip
with a content of JiraPS.zip
.
maybe we should remove the zipping in Invoke-Build -Task Package
.github/workflows/package_deploy.yml
Outdated
- name: Build | ||
shell: pwsh | ||
run: | | ||
Invoke-Build -Task Clean, Build |
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.
do we need this?
can't we download the artifact from Upload Artifact
from .github/workflows/build_and_test.yml
?
By looking into the job that ran for this PR it became quite obvious for me, that the "Deploy Module" should only consist of the step:
The current list of jobs is quite large, adds steps which could fail or need debugging and it's counter intuitive (aka: it reads poorly to have a "Build" step in the "Deploy Module") |
6a5ffc3
to
0a21726
Compare
0a21726
to
93b30b8
Compare
470222c
to
d747e84
Compare
d747e84
to
ca217bc
Compare
Description
Motivation and Context
Types of changes
Checklist