Guest User

Untitled

a guest
Oct 12th, 2021
33
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. image: microsoft/dotnet:latest
  2.  
  3. variables:
  4. # 1) Name of directory where restore and build objects are stored.
  5. OBJECTS_DIRECTORY: 'obj'
  6. # 2) Name of directory used for keeping restored dependencies.
  7. NUGET_PACKAGES_DIRECTORY: '.nuget'
  8. # 3) A relative path to the source code from project repository root.
  9. # NOTE: Please edit this path so it matches the structure of your project!
  10. SOURCE_CODE_PATH: '*/*/'
  11.  
  12. cache:
  13. # Per-stage and per-branch caching.
  14. key: "$CI_JOB_STAGE-$CI_COMMIT_REF_SLUG"
  15. paths:
  16. # Specify three paths that should be cached:
  17. #
  18. # 1) Main JSON file holding information about package dependency tree, packages versions,
  19. # frameworks etc. It also holds information where to the dependencies were restored.
  20. - '$SOURCE_CODE_PATH$OBJECTS_DIRECTORY/project.assets.json'
  21. # 2) Other NuGet and MSBuild related files. Also needed.
  22. - '$SOURCE_CODE_PATH$OBJECTS_DIRECTORY/*.csproj.nuget.*'
  23. # 3) Path to the directory where restored dependencies are kept.
  24. - '$NUGET_PACKAGES_DIRECTORY'
  25. #
  26. # 'pull-push' policy means that latest cache will be downloaded (if it exists)
  27. # before executing the job, and a newer version will be uploaded afterwards.
  28. # Such a setting saves time when there are no changes in referenced third-party
  29. # packages.
  30. #
  31. # For example, if you run a pipeline with changes in your code,
  32. # but with no changes within third-party packages which your project is using,
  33. # then project restore will happen quickly as all required dependencies
  34. # will already be there — unzipped from cache.
  35.  
  36. # 'pull-push' policy is the default cache policy, you do not have to specify it explicitly.
  37. policy: pull-push
  38.  
  39. # ### Restore project dependencies
  40. #
  41. # NuGet packages by default are restored to '.nuget/packages' directory
  42. # in the user's home directory. That directory is out of scope of GitLab caching.
  43. #
  44. # To get around this, a custom path can be specified using the '--packages <PATH>' option
  45. # for 'dotnet restore' command. In this example, a temporary directory is created
  46. # in the root of project repository, so its content can be cached.
  47. #
  48. # Learn more about GitLab cache: https://docs.gitlab.com/ee/ci/caching/index.html
  49. before_script:
  50. - 'dotnet restore --packages $NUGET_PACKAGES_DIRECTORY'
  51.  
  52. build:
  53. stage: build
  54. tags:
  55. - main
  56.  
  57. # ### Build all projects discovered from solution file.
  58. #
  59. # Note: this will fail if you have any projects in your solution that are not
  60. # .NET Core-based projects (e.g. WCF service), which is based on .NET Framework,
  61. # not .NET Core. In this scenario, you will need to build every .NET Core-based
  62. # project by explicitly specifying a relative path to the directory
  63. # where it is located (e.g. 'dotnet build ./src/ConsoleApp').
  64. # Only one project path can be passed as a parameter to 'dotnet build' command.
  65. script:
  66. - 'dotnet build --no-restore'
  67.  
  68. tests:
  69. stage: test
  70. tags:
  71. - main
  72.  
  73. # ### Run the tests
  74. #
  75. # You can either run tests for all test projects that are defined in your solution
  76. # with 'dotnet test' or run tests only for specific project by specifying
  77. # a relative path to the directory where it is located (e.g. 'dotnet test ./test/UnitTests').
  78. #
  79. # You may want to define separate testing jobs for different types of testing
  80. # (e.g. integration tests, unit tests etc).
  81. script:
  82. - 'dotnet test --no-restore'
  83.  
RAW Paste Data