SemianiakaVY/elsa-core
1
0
Fork 0
Code Issues Pull requests Actions 1 Packages Projects Releases Wiki Activity
elsa-core/appveyor.yml

123 lines
3.3 KiB
YAML
Raw Normal View History

WIP #664 - De-duplicate in-use parts of YML This is a bit of naughty scope-creep on that issue. I noticed that there's some further parts of the YML which are duplicated between the two v2 sections of the YML. It seems that the intent is mainly about deploying to MyGet on every build (in the appropriate branch) but only deploying to NuGet if building from a tag. Also, the actual build steps between these two seem to be out of sync. I've switched to a more concise way of achieving this same result, which allows me to de-duplicate the two build configs so they're using the same build process. The only other real thing I did there was sneak in the autocrlf git setting. It's just a good idea on Windows to avoid being caught out.
2021-02-25 18:49:16 +00:00
image: Previous Visual Studio 2019
environment:
Set node version and fix missing line breaks
2021-04-06 08:33:43 +00:00
nodejs_version: "14.6.0"
WIP #665 - Add changes to YML in order to trigger SonarScanner The main things going on here in the YML are: * Adding some env vars for SonarScanner * Adding the SonarScanner package as a build tool * Adding before-build/after-test steps to setup/teardown SonarScanner * Separating the "pack" step from the "build" step * Pack moved to before-package which occurs after tests pass * See https://www.appveyor.com/docs/build-configuration/#build-pipeline * Tests run with logging & code-coverage detection * Test results are added as AppVeyor artifacts
2021-02-27 12:43:04 +00:00
# AppVeyor installs Java on its build agents by default, but it
# picks an old version that's not compatible with SonarQube.
# This brings it up to date.
JAVA_HOME: "C:\\Program Files\\Java\\jdk13"
sonarcloud_org_name: elsa-workflows
Resolve #665 - Fix project name
2021-02-27 14:38:42 +00:00
sonarcloud_project_name: elsa-workflows_elsa-core
WIP #665 - Add changes to YML in order to trigger SonarScanner The main things going on here in the YML are: * Adding some env vars for SonarScanner * Adding the SonarScanner package as a build tool * Adding before-build/after-test steps to setup/teardown SonarScanner * Separating the "pack" step from the "build" step * Pack moved to before-package which occurs after tests pass * See https://www.appveyor.com/docs/build-configuration/#build-pipeline * Tests run with logging & code-coverage detection * Test results are added as AppVeyor artifacts
2021-02-27 12:43:04 +00:00
sonarcloud_api_key:
secure: qaE9kOVkGGFM7ZMf3YeliZxDU9udTCy6W5xXHJ9T+tXv5qXPMYlIdR7hyNgxW04A
WIP #664 - De-duplicate in-use parts of YML This is a bit of naughty scope-creep on that issue. I noticed that there's some further parts of the YML which are duplicated between the two v2 sections of the YML. It seems that the intent is mainly about deploying to MyGet on every build (in the appropriate branch) but only deploying to NuGet if building from a tag. Also, the actual build steps between these two seem to be out of sync. I've switched to a more concise way of achieving this same result, which allows me to de-duplicate the two build configs so they're using the same build process. The only other real thing I did there was sneak in the autocrlf git setting. It's just a good idea on Windows to avoid being caught out.
2021-02-25 18:49:16 +00:00
Apply prerelease tag to version
2021-05-28 17:18:21 +00:00
version: 2.1.0-preview.{build}
WIP #552 - Add unit test to repro Actually, this unit test does not repro the issue. Frustratingly I can't get it to save the executed workflow into MongoDB at all. I see workflow execution logs being saved, but the instance doesn't go in. I'm not sure if this is a mistake I'm making or whether I have found a different bug of some sort.
2021-03-06 17:22:37 +00:00
WIP #664 - De-duplicate in-use parts of YML This is a bit of naughty scope-creep on that issue. I noticed that there's some further parts of the YML which are duplicated between the two v2 sections of the YML. It seems that the intent is mainly about deploying to MyGet on every build (in the appropriate branch) but only deploying to NuGet if building from a tag. Also, the actual build steps between these two seem to be out of sync. I've switched to a more concise way of achieving this same result, which allows me to de-duplicate the two build configs so they're using the same build process. The only other real thing I did there was sneak in the autocrlf git setting. It's just a good idea on Windows to avoid being caught out.
2021-02-25 18:49:16 +00:00
init:
- cmd: git config --global core.autocrlf true
pull_requests:
do_not_increment_build_number: true
dotnet_csproj:
patch: true
file: '**\*.csproj'
version: '{version}'
version_prefix: '{version}'
package_version: '{version}'
assembly_version: '{version}'
file_version: '{version}'
informational_version: '{version}'
cache:
Fix various package scripts
2021-04-06 08:52:26 +00:00
- src\designer\elsa-workflows-studio\node_modules
Update appveyor.yml
2021-04-26 08:37:33 +00:00
- src\designer\bindings\aspnet\Elsa.Designer.Components.Web\node_modules
WIP #664 - De-duplicate in-use parts of YML This is a bit of naughty scope-creep on that issue. I noticed that there's some further parts of the YML which are duplicated between the two v2 sections of the YML. It seems that the intent is mainly about deploying to MyGet on every build (in the appropriate branch) but only deploying to NuGet if building from a tag. Also, the actual build steps between these two seem to be out of sync. I've switched to a more concise way of achieving this same result, which allows me to de-duplicate the two build configs so they're using the same build process. The only other real thing I did there was sneak in the autocrlf git setting. It's just a good idea on Windows to avoid being caught out.
2021-02-25 18:49:16 +00:00
- src\dashboards\blazor\ElsaDashboard.Application\node_modules
- '%APPDATA%\npm-cache'
install:
- ps: >-
Fix various package scripts
2021-04-06 08:52:26 +00:00
cd .\src\designer\elsa-workflows-studio
WIP #664 - De-duplicate in-use parts of YML This is a bit of naughty scope-creep on that issue. I noticed that there's some further parts of the YML which are duplicated between the two v2 sections of the YML. It seems that the intent is mainly about deploying to MyGet on every build (in the appropriate branch) but only deploying to NuGet if building from a tag. Also, the actual build steps between these two seem to be out of sync. I've switched to a more concise way of achieving this same result, which allows me to de-duplicate the two build configs so they're using the same build process. The only other real thing I did there was sneak in the autocrlf git setting. It's just a good idea on Windows to avoid being caught out.
2021-02-25 18:49:16 +00:00
Fix various package scripts
2021-04-06 08:52:26 +00:00
npm install --force
Update appveyor.yml
2021-04-26 08:37:33 +00:00
cd ..\bindings\aspnet\Elsa.Designer.Components.Web
WIP #664 - De-duplicate in-use parts of YML This is a bit of naughty scope-creep on that issue. I noticed that there's some further parts of the YML which are duplicated between the two v2 sections of the YML. It seems that the intent is mainly about deploying to MyGet on every build (in the appropriate branch) but only deploying to NuGet if building from a tag. Also, the actual build steps between these two seem to be out of sync. I've switched to a more concise way of achieving this same result, which allows me to de-duplicate the two build configs so they're using the same build process. The only other real thing I did there was sneak in the autocrlf git setting. It's just a good idea on Windows to avoid being caught out.
2021-02-25 18:49:16 +00:00
npm install --force
Fix various package scripts
2021-04-06 08:52:26 +00:00
cd ..\..\..\..\dashboards\blazor\ElsaDashboard.Application
Update relative paths
2021-03-17 22:02:38 +00:00
npm install --force
Fix various package scripts
2021-04-06 08:52:26 +00:00
cd ..\..\..\..
WIP #664 - De-duplicate in-use parts of YML This is a bit of naughty scope-creep on that issue. I noticed that there's some further parts of the YML which are duplicated between the two v2 sections of the YML. It seems that the intent is mainly about deploying to MyGet on every build (in the appropriate branch) but only deploying to NuGet if building from a tag. Also, the actual build steps between these two seem to be out of sync. I've switched to a more concise way of achieving this same result, which allows me to de-duplicate the two build configs so they're using the same build process. The only other real thing I did there was sneak in the autocrlf git setting. It's just a good idea on Windows to avoid being caught out.
2021-02-25 18:49:16 +00:00
Re-enable sonar cloud
2021-05-26 10:31:04 +00:00
dotnet tool install --global dotnet-sonarscanner
Accommodate for Tailwind 2 breaking changes and fix build script (temporarily disabling sonar cube)
2021-04-06 08:26:17 +00:00
Update appveyor
2021-05-06 20:17:41 +00:00
before_build:
- cmd: >-
docker-compose -f docker-compose.yaml up -d mongodb postgres
Re-enable sonar cloud
2021-05-26 10:31:04 +00:00
- ps: >-
if(-Not $env:APPVEYOR_PULL_REQUEST_NUMBER) {
& dotnet-sonarscanner begin
/k:$env:sonarcloud_project_name
/v:AppVeyor_build_$env:APPVEYOR_BUILD_VERSION
/o:$env:sonarcloud_org_name
/s:$env:APPVEYOR_BUILD_FOLDER\.SonarQube.Analysis.xml
/d:sonar.host.url="https://sonarcloud.io"
/d:sonar.login=$env:sonarcloud_api_key
/d:sonar.cs.xunit.reportsPaths=$env:APPVEYOR_BUILD_FOLDER\**\TestResults\TestResults.xml
/d:sonar.cs.opencover.reportsPaths=$env:APPVEYOR_BUILD_FOLDER\**\TestResults\*\coverage.opencover.xml
/d:sonar.branch.name=$env:APPVEYOR_REPO_BRANCH
}
Update docker-compose and appveyor with Postgres
2021-05-06 17:26:32 +00:00
Update appveyor.yml
2021-04-01 09:05:58 +00:00
build_script:
- ps: >-
Fix various package scripts
2021-04-06 08:52:26 +00:00
cd .\src\designer\elsa-workflows-studio
npm run build
Update docker-compose and appveyor with Postgres
2021-05-06 17:26:32 +00:00
Update appveyor.yml
2021-04-26 08:37:33 +00:00
cd ..\bindings\aspnet\Elsa.Designer.Components.Web
Update docker-compose and appveyor with Postgres
2021-05-06 17:26:32 +00:00
Accommodate for Tailwind 2 breaking changes and fix build script (temporarily disabling sonar cube)
2021-04-06 08:26:17 +00:00
npm run build
Update docker-compose and appveyor with Postgres
2021-05-06 17:26:32 +00:00
Accommodate for Tailwind 2 breaking changes and fix build script (temporarily disabling sonar cube)
2021-04-06 08:26:17 +00:00
cd ..\..\..\..\dashboards\blazor\ElsaDashboard.Application
Update docker-compose and appveyor with Postgres
2021-05-06 17:26:32 +00:00
Update appveyor.yml
2021-04-01 09:05:58 +00:00
npm run build
Update docker-compose and appveyor with Postgres
2021-05-06 17:26:32 +00:00
Accommodate for Tailwind 2 breaking changes and fix build script (temporarily disabling sonar cube)
2021-04-06 08:26:17 +00:00
cd ..\..\..\..\
Update docker-compose and appveyor with Postgres
2021-05-06 17:26:32 +00:00
Update appveyor.yml
2021-04-01 09:05:58 +00:00
dotnet build
Update appveyor
2021-05-06 20:17:41 +00:00
# before_test:
WIP #751 - AppVeyor also needs to create the DB
2021-04-07 20:09:26 +00:00
WIP #664 - De-duplicate in-use parts of YML This is a bit of naughty scope-creep on that issue. I noticed that there's some further parts of the YML which are duplicated between the two v2 sections of the YML. It seems that the intent is mainly about deploying to MyGet on every build (in the appropriate branch) but only deploying to NuGet if building from a tag. Also, the actual build steps between these two seem to be out of sync. I've switched to a more concise way of achieving this same result, which allows me to de-duplicate the two build configs so they're using the same build process. The only other real thing I did there was sneak in the autocrlf git setting. It's just a good idea on Windows to avoid being caught out.
2021-02-25 18:49:16 +00:00
test_script:
WIP #665 - Add changes to YML in order to trigger SonarScanner The main things going on here in the YML are: * Adding some env vars for SonarScanner * Adding the SonarScanner package as a build tool * Adding before-build/after-test steps to setup/teardown SonarScanner * Separating the "pack" step from the "build" step * Pack moved to before-package which occurs after tests pass * See https://www.appveyor.com/docs/build-configuration/#build-pipeline * Tests run with logging & code-coverage detection * Test results are added as AppVeyor artifacts
2021-02-27 12:43:04 +00:00
- ps: dotnet test --collect:"XPlat Code Coverage" --logger:xunit -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=opencover
after_test:
Attempt to fix build; after_test "executed with exception" I'm a little confused as to how this happened. It could relate to an exit code sent by SonarScanner. I'm going to combine these two commands into a single step so that if SonarScanner drops a non-zero exit code, it should still continue on past it.
2021-02-27 19:32:46 +00:00
- ps: >-
Fix spacing
2021-04-06 08:27:53 +00:00
dotnet pack Elsa.sln --include-symbols /p:Version="$env:APPVEYOR_BUILD_VERSION"
WIP #664 - De-duplicate in-use parts of YML This is a bit of naughty scope-creep on that issue. I noticed that there's some further parts of the YML which are duplicated between the two v2 sections of the YML. It seems that the intent is mainly about deploying to MyGet on every build (in the appropriate branch) but only deploying to NuGet if building from a tag. Also, the actual build steps between these two seem to be out of sync. I've switched to a more concise way of achieving this same result, which allows me to de-duplicate the two build configs so they're using the same build process. The only other real thing I did there was sneak in the autocrlf git setting. It's just a good idea on Windows to avoid being caught out.
2021-02-25 18:49:16 +00:00
artifacts:
- path: '**/*.nupkg'
name: Packages
WIP #665 - Add changes to YML in order to trigger SonarScanner The main things going on here in the YML are: * Adding some env vars for SonarScanner * Adding the SonarScanner package as a build tool * Adding before-build/after-test steps to setup/teardown SonarScanner * Separating the "pack" step from the "build" step * Pack moved to before-package which occurs after tests pass * See https://www.appveyor.com/docs/build-configuration/#build-pipeline * Tests run with logging & code-coverage detection * Test results are added as AppVeyor artifacts
2021-02-27 12:43:04 +00:00
- path: '**/TestResults/TestResults.xml'
WIP #664 - De-duplicate in-use parts of YML This is a bit of naughty scope-creep on that issue. I noticed that there's some further parts of the YML which are duplicated between the two v2 sections of the YML. It seems that the intent is mainly about deploying to MyGet on every build (in the appropriate branch) but only deploying to NuGet if building from a tag. Also, the actual build steps between these two seem to be out of sync. I've switched to a more concise way of achieving this same result, which allows me to de-duplicate the two build configs so they're using the same build process. The only other real thing I did there was sneak in the autocrlf git setting. It's just a good idea on Windows to avoid being caught out.
2021-02-25 18:49:16 +00:00
deploy:
# Deploy to MyGet on every build (in the appropriate branch)
- provider: NuGet
server: https://www.myget.org/F/elsa-2/api/v2/package
api_key:
secure: JfESkwmLdWU7dzvoqKPUfMemb00wX8AEYxeHCsYWTX1LfTeECdmKdZxz7IVUpebb
skip_symbols: true
on:
Update appveyor
2021-05-04 09:06:16 +00:00
branch: master
Update docker-compose and appveyor with Postgres
2021-05-06 17:26:32 +00:00
WIP #664 - De-duplicate in-use parts of YML This is a bit of naughty scope-creep on that issue. I noticed that there's some further parts of the YML which are duplicated between the two v2 sections of the YML. It seems that the intent is mainly about deploying to MyGet on every build (in the appropriate branch) but only deploying to NuGet if building from a tag. Also, the actual build steps between these two seem to be out of sync. I've switched to a more concise way of achieving this same result, which allows me to de-duplicate the two build configs so they're using the same build process. The only other real thing I did there was sneak in the autocrlf git setting. It's just a good idea on Windows to avoid being caught out.
2021-02-25 18:49:16 +00:00
# Deploy to NuGet on builds from tags only
- provider: NuGet
api_key:
secure: WC5CCcM5ksWOJbv925FNjv91KsfqHfwEe0A61FMNB27IxvttwJsvBC9XYwK+wQnp
skip_symbols: true
on:
Update appveyor
2021-05-04 09:06:16 +00:00
branch: master
Remove docker code
2021-04-02 11:23:04 +00:00
APPVEYOR_REPO_TAG: true
Reference in a new issue Copy permalink