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

Add package workflow #491

Draft
wants to merge 10 commits into
base: develop
Choose a base branch
from
Draft

Add package workflow #491

wants to merge 10 commits into from

Conversation

mkellerman
Copy link

Description

Motivation and Context

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist

  • My code follows the code style of this project.
  • I have added Pester Tests that describe what my changes should do.
  • I have updated the documentation accordingly.

@@ -204,3 +204,37 @@ jobs:
name: ${{ runner.os }}-Unit-Tests
path: Test*.xml
if: ${{ always() }}

package:
name: Package
Copy link
Member

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.

Copy link
Author

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.

push:
branches:
- feature/package-artifact
workflow_dispatch:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

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. 🤷‍♂️

shell: pwsh
run: |
./Tools/setup.ps1
Invoke-Build -Task ShowInfo
Copy link
Member

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

Copy link
Author

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.

- name: Package
shell: pwsh
run: |
Invoke-Build -Task Package
Copy link
Member

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?

Copy link
Author

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.

run: |
Invoke-Build -Task Package
- name: Upload Artifact
uses: actions/upload-artifact@v3
Copy link
Member

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

Copy link
Author

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]'
Copy link
Member

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

https://learn.microsoft.com/en-us/powershell/gallery/concepts/module-prerelease-support?view=powershellget-3.x#identifying-a-module-version-as-a-prerelease

  • 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]'
Copy link
Member

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')) {
Copy link
Member

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)

- name: Upload Artifact
uses: actions/upload-artifact@v3
with:
name: JiraPS.zip
Copy link
Member

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

- name: Build
shell: pwsh
run: |
Invoke-Build -Task Clean, Build
Copy link
Member

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?

@lipkau
Copy link
Member

lipkau commented Dec 19, 2023

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:

  • Set up job
  • actions/checkout (we need the deployment code after all)
  • (missing) Download Artifact
  • caching (I think)
  • Setup
  • Deploy
  • cleanup which is not managed by us

image

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")

@lipkau lipkau force-pushed the feature/package-artifact branch 2 times, most recently from 6a5ffc3 to 0a21726 Compare December 20, 2023 14:37
@lipkau lipkau changed the base branch from master to develop December 21, 2023 13:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants