Migrate VarTools from Jenkins to Github Actions #11
Conversation
This is still a problem in the build and publish workflow
For upgrades needed for CI system
For CI system
This should be removed in the future
This was never updated
This is not valid in github actions
I dont think that is needed at all
This was updated for some reason
These auto updated
Instead of cloning a specific version. You can still close a specific version but the agent has the latest main so its a good default
This will help confirm that upgrades are installed
Some scripts MAY not handle relative paths properly
This is copied from the build workflow to keep the same standard. I think there is a way to combine these workflows but only run the publish step conditionally but I am not going to focus on that yet
We are migrating to Github Actions
| cd ./main | ||
| git lfs pull | ||
| - name: Install AS upgrades | ||
| run: python.exe C:/Tools/AsPython/InstallUpgrades.py ${{ github.workspace }}/main/upgrades -asp AS411 -r --logLevel DEBUG |
There was a problem hiding this comment.
Looks like this is dependent upon AsPython already existing on the runner, right? This feels like the correct way to do it in general, but how do you propose we handle AsPython changes if for example we only want a subset of all repos to use a new version?
There was a problem hiding this comment.
The runner will have AsPython main (pulled daily). IF you wanted a specific version, no problem. Add a checkout and use that instead. Example:
# This workflow will run build an AS project and publish the libraries to the github package registry
name: Build Libraries
on:
push:
branches-ignore:
- 'main'
jobs:
build-libraries:
runs-on: [AS411]
permissions:
contents: read
packages: write
steps:
- uses: actions/checkout@v4
with:
submodules: 'true'
path: "main"
lfs: true
- uses: actions/checkout@v4
with:
repository: "loupeteam/ASPython"
submodules: 'true'
ref: "bugfix/pvi-error-code"
path: "AsPython"
- name: Fix LFS
run: |
cd ./main
git lfs pull
- name: Install AS upgrades
shell: pwsh
run: |
Set-Location -Path ./main/upgrades
& $PWD/install.ps1
- run: python.exe ./AsPython/CmdLineBuild.py ./main/example/AsProject/AsProject.apj -c Intel ARM -bm Rebuild -sim --logLevel DEBUG
- run: python.exe ./AsPython/CmdLineExportLib.py ./main/example/AsProject/AsProject.apj -dest ./libs -c Intel ARM -wl vartools -l DEBUG -o -bm "None"
.github/workflows/buildPublish.yml
Outdated
| on: | ||
| push: | ||
| branches: | ||
| - main | ||
| tags: | ||
| - v* |
There was a problem hiding this comment.
I think this setup with the two workflows makes sense - you want to auto-build and export commits from all branches except for main, and you want to build and publish for either main pushes or specific tag events. Am I understanding the intent correctly?
There was a problem hiding this comment.
That is correct.
I think maybe a better solution would be one workflow that has steps that are conditional but I didnt want to spend time on that yet.
| # set environment variables | ||
| $env:AS_VERSION_SHORT = 'AS411' | ||
| Get-ChildItem "$PWD" -Recurse -Filter *.exe | Foreach-Object { | ||
| Write-Output "installing $($_.Name)"; | ||
| Write-Verbose "Into C:\BrAutomation\$env:AS_VERSION_SHORT"; | ||
| & $_.FullName -G='C:\BrAutomation' -V="C:\BrAutomation\$env:AS_VERSION_SHORT" -R | Out-Null; | ||
| if($LASTEXITCODE -ne 0) { | ||
| Write-Error "Error installing $($_.Name). Exit code $LASTEXITCODE"; | ||
| exit 1; | ||
| } | ||
| } |
There was a problem hiding this comment.
It looks like you're now using AsPython for upgrades, is this Powershell script still needed?
There was a problem hiding this comment.
It is not needed but I like the script. It can be used by people who are new to the project that want to install the upgrades
|
Is this PR something we want to merge? |
|
I think so |
# Conflicts: # example/AsProject/AsProject.apj # example/AsProject/Physical/Intel/5PC900_TS17_04/Cpu.pkg # example/AsProject/Physical/Intel/Hardware.hw
What:
Migrates Jenkins pipelines over to Github Actions. To make sure the server has necessary upgrades, they are included in the repository and installed at build time.
Why:
This will allow the workflow logs to be publicly accessible. This repository will be used as a test case to see if Github Actions can be used instead of Jenkins.