Simplify appveyor.yml#12540
Conversation
This comment has been minimized.
This comment has been minimized.
2c06944 to
260bd1f
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
4378ec0 to
6da20f9
Compare
This comment has been minimized.
This comment has been minimized.
77370e1 to
72cdb74
Compare
This comment has been minimized.
This comment has been minimized.
d78931c to
5ab5ea5
Compare
feerrenrut
left a comment
There was a problem hiding this comment.
Do you plan for this to be merged (to preserve the movement history)? If so, it would be nice to add some reasoning to each of the commit messages.
In the description you say:
as the repo isn't cloned until after the init phase, setBuildVersionVars.ps1 was moved until after that, into the install build phase
- this means we don't update the appveyor build number until after a successful clone
Can you elaborate on why the timing of build number increment should change?
The first commit would be easier to review if it was a straight move of code (no modifications). It's ok if this commit won't build, just make it clear in the commit message that it doesn't build and is part of a larger change. Could you move the modifications to a subsequent commit please?
I actually can review this with various incantations of --color-moved and --color-moved-whitespace but it is slow and likely error prone.
| # The server side deploy code ('nvdaAppveyorHook') relies on artifacts, they must be uploaded first. | ||
| # For ordering of appveyor yml phases, see: https://www.appveyor.com/docs/build-configuration/#build-pipeline |
There was a problem hiding this comment.
This seem obvious, but mistakes have been made here before. I think it is a shame to lose the "why" provided in some of these removed comments. I think I'd prefer them in the yml file (for locality of reference) but if you're concerned with duplication and want them removed then at least make sure they are captured in the readme file.
There was a problem hiding this comment.
Preserving these inline comments here shouldn't be an issue but all old comments should be captured in the README. To get a real picture of the process, before making any changes to this file, one would have to refer (and reflect changes) to the README anyway.
If there are multiple appveyor-*.yml files though, I imagine the README could get confusing and information (or references to sections) might be better deferred to inline comments.
* lint and reference powershell code moved to files from appveyor.yml
df9c5ea to
170fce6
Compare
I've refactored this PR to be better as a merge commit. I'm planning on squashing all subsequent commits after the code move into "Simplify appveyor.yml (#12540)" - with summary/reasoning like the first bullet point.
It's more a matter of necessity. Before our repo is cloned (which happens after
The first commit is now generated as the result of the following script: sed -n '25,60 p' appveyor.yml > appveyor/scripts/setBuildVersionVars.ps1
sed -n '66,80 p' appveyor.yml > appveyor/scripts/decryptFilesForSigning.ps1
sed -n '87,106 p' appveyor.yml > appveyor/scripts/setSconsArgs.ps1
sed -n '112,118 p' appveyor.yml > appveyor/scripts/tests/translationCheck.ps1
sed -n '125,134 p' appveyor.yml > appveyor/scripts/buildSymbolStore.ps1
sed -n '146,172 p' appveyor.yml > appveyor/scripts/installNVDA.ps1
sed -n '177,188 p' appveyor.yml > appveyor/scripts/tests/unitTests.ps1
sed -n '192,223 p' appveyor.yml > appveyor/scripts/tests/lintCheck.ps1
sed -n '227,239 p' appveyor.yml > appveyor/scripts/tests/systemTests.ps1
sed -n '244,244 p' appveyor.yml > appveyor/scripts/tests/checkTestFailure.ps1
sed -n '256,265 p' appveyor.yml > appveyor/scripts/uploadArtifacts.ps1
sed -n '271,306 p' appveyor.yml > appveyor/scripts/deployScript.ps1
sed -n '311,319 p' appveyor.yml > appveyor/scripts/pushPackagingInfo.ps1
sed -i'' -e '311,319 d' appveyor.yml
sed -i'' -e '271,306 d' appveyor.yml
sed -i'' -e '256,265 d' appveyor.yml
sed -i'' -e '244,244 d' appveyor.yml
sed -i'' -e '227,239 d' appveyor.yml
sed -i'' -e '192,223 d' appveyor.yml
sed -i'' -e '177,188 d' appveyor.yml
sed -i'' -e '146,172 d' appveyor.yml
sed -i'' -e '125,134 d' appveyor.yml
sed -i'' -e '112,118 d' appveyor.yml
sed -i'' -e '87,106 d' appveyor.yml
sed -i'' -e '66,80 d' appveyor.yml
sed -i'' -e '25,60 d' appveyor.yml |
- lint and reference powershell code moved to files from appveyor.yml - setBuildVersion vars after init and repo clone - move translation check to tests - move some inline cmd into ps scripts - remove redundant exit checks - add appveyor readme - remove markdown from build url message as it is not compatible with slack and appveyor
170fce6 to
84488fe
Compare
| - if ERRORLEVEL 1 exit %ERRORLEVEL% | ||
| - cd .. | ||
| - ps: appveyor\scripts\buildSymbolStore.ps1 | ||
| - 7z a -tzip -r output\symbols.zip symbols\*.dl_ symbols\*.ex_ symbols\*.pd_ |
There was a problem hiding this comment.
@seanbudd As this command now manually mentions the symbols directory in each file to be included, rather than changing directory to symbols first, the zip file now contains a subdirectory called symbols with everything inside.
This is not what our server expects, so when the zip file is extracted, we end up with a symbols directory within our symbol server.
We should change this line back to
cd symbols
7z a -tzip -r ..\output\symbols.zip *.dl_ *.ex_ *.pd_
Though I don't know the full reasoning as to why changing directories was avoided here.
There was a problem hiding this comment.
This was just to simplify code. I will revert this.
Summary of the issue: The server expects the symbols archive to be structured as ./*.ex_ not ./symbols/*.ex_. Due to changes in #12540, the symbols archive has been restructured to ./symbols/*.ex_. This is because 7zip structures the archive based on relative paths. Description of how this pull request fixes the issue: Reverts the 7zip symbol build to the old behaviour
Link to issue number:
None
Summary of the issue:
If a developer wishes to use multiple appveyor.yml files, there would be a lot of code duplication. In order to make changes to the AppVeyor build process(es), inline powershell scripts must be edited. Inline powershell scripts are harder to lint and parse than individual files within IDEs.
Description of how this pull request fixes the issue:
Simplifies the
appveyor.ymlfile by putting the powershell scripts into separate files.Note to reviewers: I would recommend reading through these changes, and then compare them to the individual commits and README. The git bash script is a tool you can use to review the final changes or specific commits. I've noted some proposed changes of behaviour, but otherwise original behaviour is intended.
Changes:
appveyor\README.mdand created an outline of AppVeyor proccess in theappveyor\README.md$ErrorActionPreference = "Stop";to the start of each except our test scripts which are allowed to failHEAD. To see the diff at a specific commit, check it out, as the files specified bylsmust be checked out locally.initphase,setBuildVersionVars.ps1was moved until after that, into theinstallbuild phasetest_scriptbuild phaseTesting strategy:
decryptFilesForSigning.ps1as this acts upon secure files when on non PR builds.Known issues with pull request:
None needed
Change log entries:
None needed
Code Review Checklist: