I'm going to route all the traffic from running pipeline throught my remote host. Unfotunately, when a process run into dotnet restore it fails. I have thoughts about proxy issues but all stuff worked as well before a moment. Direct me, please, into right direction.
Here the environment
bibucket-pipeline.yml file:
image: microsoft/dotnet:2.1-sdk
pipelines:
default:
- step:
caches:
- dotnetcore
script:
- curl https://api.ipify.org
- ssh -fN -C -4 -D 41337 user#remotehost
- export http_proxy='socks5://localhost:41337'
- export https_proxy='socks5://localhost:41337'
- curl https://api.ipify.org
- dotnet restore
- dotnet build
- dotnet test
dotnet --info:
.NET Core SDK (reflecting any global.json):
Version: 2.1.302
Commit: 9048955601
Runtime Environment:
OS Name: debian
OS Version: 9
OS Platform: Linux
RID: debian.9-x64
Base Path: /usr/share/dotnet/sdk/2.1.302/
Host (useful for support):
Version: 2.1.2
Commit: 811c3ce6c0
.NET Core SDKs installed:
2.1.302 [/usr/share/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Errors:
/usr/share/dotnet/sdk/2.1.302/NuGet.targets(114,5): error : Unable to
load the service index for source https://api.nuget.org/v3/index.json.
[/opt/atlassian/pipelines/agent/build/PCT.sln]
/usr/share/dotnet/sdk/2.1.302/NuGet.targets(114,5): error : Only the
'http' scheme is allowed for proxies.
[/opt/atlassian/pipelines/agent/build/PCT.sln]
By now (Dec 18), dotnet restore still does not support socks5 proxy. Use HTTP proxy instead.
I use privoxy to convert socks5 proxy traffic to http proxy.
Related
A few months ago I did a proof of concept for a CI/CD pipeline on gitlab for my dotnet core API deployed on AWS elastic beanstalk. At the time I got it to work.
I'm now attempting to actually implement the solution properly, but it's no longer working. The appropriate code in my yml file is as follows:
stages:
- deploy_testing
deploy-testing-job:
stage: deploy_testing
image: mcr.microsoft.com/dotnet/sdk:6.0
before_script:
- dotnet tool install -g Amazon.ElasticBeanstalk.Tools
- export PATH="$PATH:/root/.dotnet/tools"
- apt update
- apt-get --assume-yes install zip
script:
- dotnet restore
- dotnet eb deploy-environment --profile my_profile --configuration Release --framework net6.0-windows --project-location "MyProject.Api/" --self-contained true --region $AWS_REGION --application $APP_NAME --environment $APP_ENV_NAME --solution-stack "64bit Windows Server Core 2019 v2.11.0 running IIS 10.0"
Now I started getting an error:
Error creating Elastic Beanstalk application: User: arn:aws:iam::1234:user/gitlab is not authorized to perform: elasticbeanstalk:CreateApplication on resource: arn:aws:elasticbeanstalk:my-region:1234:application/my-application
I found this strange since I confirmed that I correctly identified both an existing application and environment.
Just to see what would happen, I temporarily attached Create Application permission to the appropriate gitlab-elastic-beanstalk policy and now I get the error:
Error creating Elastic Beanstalk application: Application my-application already exists.
Why is eb deploy-environment attempting to recreate the whole application / environment?
With AzureDevOps I get the following error since yesterday, before that everything worked fine for months:
The current Compose file version is not compatible with your engine version. Please
upgrade your Compose file to a more recent version, or set a COMPOSE_API_VERSION in your
environment.
In Azure-DevOps I use in the pipeline:
- task: DockerCompose#0
displayName: Run services
inputs:
containerregistrytype: 'Container Registry'
dockerComposeFile: 'build/docker/docker-compose.yml'
dockerComposeFileArgs: 'DOCKER_BUILD_SOURCE=$(System.DefaultWorkingDirectory)'
action: 'Run services'
buildImages: false
My docker-compose (docker-compose.yml) file looks like this (details changed):
version: '3.0'
services:
sqlserver:
image: willh/mssql-server-windows-developer:latest
container_name: sqlserver
shm_size: 4gb
ports:
- "1433:1433"
environment:
- ACCEPT_EULA=Y
- SA_PASSWORD=a(!)Passcode
I realized the updated microsoft build agent Image:
from: https://github.com/actions/runner-images/blob/win22/20230129.1/images/win/Windows2022-Readme.md
which worked well
containing:
Docker 20.10.23
Docker Compose v1 1.29.2
Docker Compose v2 2.15.1
Docker-wincred 0.7.0
to: https://github.com/actions/runner-images/blob/win22/20230206.1/images/win/Windows2022-Readme.md
which does not work
containing:
Docker 23.0.0
Docker Compose v1 1.29.2
Docker Compose v2 2.15.1
Docker-wincred 0.7.0
But i do not see how I can get it to work again.
Which COMPOSE_API_VERSION would I have to set? The same as I have in the docker-compose.yml file?
The error message you are receiving indicates that the version of Docker Compose being used is not compatible with the version specified in your Docker Compose file (docker-compose.yml). The version specified in your Docker Compose file is 3.0, but the version of Docker Compose installed on the updated build agent image is 2.15.1.
To resolve this issue, you can either upgrade the Docker Compose file to a version that is compatible with the installed version of Docker Compose, or you can set the COMPOSE_API_VERSION environment variable to the version specified in the Docker Compose file.
In your case, you could set the COMPOSE_API_VERSION environment variable to 3.0:
env:
COMPOSE_API_VERSION: '3.0'
and add this environment variable to the Azure DevOps pipeline task:
- task: DockerCompose#0
displayName: Run services
inputs:
containerregistrytype: 'Container Registry'
dockerComposeFile: 'build/docker/docker-compose.yml'
dockerComposeFileArgs: 'DOCKER_BUILD_SOURCE=$(System.DefaultWorkingDirectory)'
action: 'Run services'
buildImages: false
env:
COMPOSE_API_VERSION: '3.0'
This should allow the pipeline task to use the correct version of Docker Compose and avoid the compatibility error.
I'm setting up Bitbucket Pipelines to build a project using node 14.21.2, but it is being run with an image using node 4.2.1.
Here is the configuration I am using and the build output.
Pipelines config
definitions:
services:
npmbuild:
image: node:14.21.2
variables:
NPM_TOKEN: $NPM_TOKEN
pipelines:
default:
- step:
name: Build Production
services:
- npmbuild
script:
- node -v
Output
+ node -v
v4.2.1
N/A: version "v14.21.2" is not yet installed
How can I change this to use the correct version of node?
UPDATE: I have a workaround where I just specify the image at the root level, but my question still remains as to why setting the image at the step level didn't work as expected.
The jHipster 7.9 release uses testcontainers by default for running Java integration tests. This is causing problems with my existing bitbucket-pipeline.
Is there a way to switch back to the previous test running approach used by jHipster for integration tests?
I did not find a straightforward way to switch back to the old handling of postgresql databases as part of the build integration tests.
I instead kept with the newer testcontainers approach for postgresql Spring #IntegrationTest tests. I needed to disable ryuk, and I also needed to increase the bitbucket RAM for the step running the integration tests with the Bitbucket 2x feature.
bitbucket-pipelines.yml
image: .... jhipster 7.9.2 based image ...
definitions:
services:
docker:
memory: 3000
pipelines:
default:
- step:
name: Clean & Build
....
- step:
name: Test and Verify
size: 2x
caches: ....
services:
- docker
script:
- export TESTCONTAINERS_RYUK_DISABLED=true
- ./mvnw -Pprod clean verify sonar:sonar
...
Deploying azure function using appveyor is straightforward as described by this article - https://alastairchristian.com/deploying-azure-functions-from-appveyor-75fe03771d0c#.x7stvprna
Further what I am not able to figure out is how to deploy a custom dll (library part of the same repo) in the /bin folder to be able to use #r and use the reference.
Manual process is just to copy the dll in the /bin folder using Kudu and start using it.
Also refer to this discussion on appveyor - http://help.appveyor.com/discussions/questions/2842-deployment-to-azure-function-app
Here is my appveyor.yml -
-
branches:
only:
- master
version: 0.0.{build}
os: Visual Studio 2015
configuration: Release
init:
- nuget sources update -Name nuget.org -Source https://api.nuget.org/v3/index.json
environment:
SolutionDir: $(APPVEYOR_BUILD_FOLDER)\
cache:
- packages -> **\packages.config
assembly_info:
patch: true
file: '**\AssemblyInfo.*'
assembly_version: '{version}'
assembly_file_version: '{version}'
assembly_informational_version: '{version}'
before_build:
- nuget restore -verbosity detailed
build:
verbosity: normal
project: MyLibrary\MyLibrary.csproj
publish_wap: true
publish_azure: true
parallel: true
artifacts:
- path: AzureFuncCIPOC
name: AzureFuncCIPOC
deploy:
- provider: WebDeploy
server: https://functioncipoc.scm.azurewebsites.net:443/msdeploy.axd?site=FunctionCIPOC
website: FunctionCIPOC
username: $FunctionCIPOC
password:
secure: <secure>
artifact: AzureFuncCIPOC
If your build process is building that library and moving the output (your custom DLL) so that is is packaged in the artifact created by AppVeyor, it will be deployed with the scripts.
I was able to copy the required dlls as project post-build event and then use the same .yml as posted in question to achieve what I was after. Really hope that VS 2017 will have better support for this when Azure Functions tools for VS2017 are launched.
below is the post-build event command
if not exist "$(SolutionDir)AzureFuncCIPOC\\ManualTriggerCSharp\bin\" mkdir "$(SolutionDir)AzureFuncCIPOC\\ManualTriggerCSharp\bin\"
copy /y "$(TargetDir)" "$(SolutionDir)AzureFuncCIPOC\\ManualTriggerCSharp\bin\"