Continuous Integration/build engineering/devops thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Continuous Integration/build engineering/devops thread

Boz0r: Sep 7, 2006; The Rocketship in action.

What are peoples' thoughts on TeamCity vs Jenkins?

# ¿ Feb 2, 2016 12:55

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 17:10

Boz0r: Sep 7, 2006; The Rocketship in action.

the talent deficit posted:

you should stick with what you have

What I have is four developers trying to do weird patch jobs for each deploy. I think anything would be better than that.

# ¿ Feb 2, 2016 20:56

Boz0r: Sep 7, 2006; The Rocketship in action.

After further examination of the problem, we actually just want to a build server that can do tests on the build before the code can be sent to the version control server. And just have a button on the build server that spits out the newest version, that we'll manually deploy.

# ¿ Feb 4, 2016 14:41

Boz0r: Sep 7, 2006; The Rocketship in action.

I don't know what it's called, I just want to be able to click a button in IntelliJ that sends the code to TeamCity or whatever. That builds it, runs all the tests and verifies policies and, if it's supergreen, passes the code along to SVN.

EDIT: I think JetBrains calls it a delayed commit.

# ¿ Feb 4, 2016 15:24

Boz0r: Sep 7, 2006; The Rocketship in action.

I get an error when I use a Visual Studio Test task in my build pipeline in ADO. I have a unit test project using xUnit and targeting .NET Core 3.0.

code:

[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.4.0 (64-bit .NET Core 3.0.2)
[xUnit.net 00:00:00.90]   Discovering: Unittest.xUnit
[xUnit.net 00:00:00.95]   Discovered:  Unittest.xUnit
[xUnit.net 00:00:00.95]   Starting:    Unittest.xUnit
[xUnit.net 00:00:01.14]   Finished:    Unittest.xUnit
  &#8730; Unittest.Test1 [114ms]
  &#8730; Unittest.Test2 [< 1ms]
  &#8730; Unittest.Test3 [< 1ms]
  &#8730; Unittest.Test3 [< 1ms]
  &#8730; Unittest.Test4 [< 1ms]
  &#8730; Unittest.Test5 [< 1ms]
##[error]Unable to find d:\a\1\s\Project\Test\Unittest.xUnit\obj\Release\netcoreapp3.0\Unittest.xUnit.deps.json. Make sure test project has a nuget reference of package "Microsoft.NET.Test.Sdk".

The project already has a nuget reference to that package. I saw some posts where people got it working by changing the target framework from .NET Framework to .NET Core, by my project is already .NET Core.

# ¿ Jan 27, 2020 08:59

Boz0r: Sep 7, 2006; The Rocketship in action.

I have a couple of .NET MVC/WebAPI projects, both Core and Framework on Azure, calling each other with http requests. I'd like my build pipeline to start these web services, run some integration tests, and kill the services/servers when they're done.
How do I do this?

Some of the services make external calls that I use Moq to mock in my unit tests.
How would I do the same thing in those integration tests?

# ¿ Mar 9, 2020 13:15

Boz0r: Sep 7, 2006; The Rocketship in action.

New Yorp New Yorp posted:

Can you run the environment in containers? If so, docker compose can help you here.

I don't know. I don't know a lot about Azure yet. Most of the apps are pretty simple MVC apps.

New Yorp New Yorp posted:

If not, how do you run the integration tests locally? If you have to manually go and run things and set up an environment that will make the tests pass, then that's a problem. Solve it for a developer's local machine and you've solved the problem universally. Generally, running integration tests after deployment against a dev environment is an okay approach for this kind of thing. Also keep in mind that integration tests are mostly intended to verify that services are communicating properly -- failure means "these things can't talk". Proving they can talk in a local environment isn't giving you much of a signal.

We haven't made any integration tests yet. I'm trying to get the team to prioritize it

# ¿ Mar 9, 2020 14:38

Boz0r: Sep 7, 2006; The Rocketship in action.

New Yorp New Yorp posted:

Containers / Docker Compose have nothing to do with Azure.

Don't prioritize integration tests, prioritize unit tests. Unit tests verify correct behavior of units of code (classes, methods, etc). Integration tests verify that the correctly-working units of code can communicate to other correctly-working units of code (service A can talk to service B). Both serve an important purpose, but the bulk of your test effort should go into unit tests.

We've mad a lot of unit tests. I haven't checked the actual percent, but our code coverage is pretty good.

# ¿ Mar 9, 2020 15:28

Boz0r: Sep 7, 2006; The Rocketship in action.

I have a C# solution on ADO with a bunch of projects, some target .NET Framework and some target .NET Core. On my own machine, all bins are put in the /bin/ folder, but when ADO builds it, the core projects get put in /bin/Release/ or something similar, which breaks some of my scripts. How do I fix this?

EDIT: Fixed it. One of the projects' csproj only had a debug conditional with an absolute path, the others had one for both configurations.

Boz0r fucked around with this message at 09:05 on Mar 20, 2020

# ¿ Mar 20, 2020 08:38

Boz0r: Sep 7, 2006; The Rocketship in action.

We've got 10+ build pipelines in ADO with solutions that include a bunch of common projects. I'd like to trigger these builds on changes to the individual projects, but also the common projects. Is there a better way of setting up some trigger dependencies instead of adding all the paths manually?

# ¿ Apr 3, 2020 09:49

Boz0r: Sep 7, 2006; The Rocketship in action.

New Yorp New Yorp posted:

Use versioned packages for common dependencies. You shouldn't force consumers of common libraries to take a new version of a common library, they should opt in on their own schedule.

That's the plan for the future, but in this initial phase we're making a shitload of changes.

# ¿ Apr 3, 2020 18:03

Boz0r: Sep 7, 2006; The Rocketship in action.

Gyshall posted:

Even still, isn't it more chaotic to always use broken dependencies? Why not pin package versions?

But that would make sense, and our customer doesn't like that kind of thing.

# ¿ Apr 4, 2020 10:17

Boz0r: Sep 7, 2006; The Rocketship in action.

What is it called in Azure DevOps when committed code gets rejected if it doesn't build and pass all tests? People from our team break our pipelines all the time and I'm sick of it.

# ¿ May 11, 2020 07:47

Boz0r: Sep 7, 2006; The Rocketship in action.

Mr Shiny Pants posted:

A good thing(tm).

Thank you, but I can't find out how to set it up if I don't know what they call it.

# ¿ May 11, 2020 08:52

Boz0r: Sep 7, 2006; The Rocketship in action.

We use dotnet pack to build nuget packages. How do I add a branch name to the package name?

# ¿ Jun 8, 2020 08:39

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 17:10

Boz0r: Sep 7, 2006; The Rocketship in action.

NihilCredo posted:

I would strongly recommend putting the branch name in the version tag instead (eg "1.2.3.4-bozorsexperiment"), or in some other annotation. It's a fairly conventional assumption that project name == package name == root namespace, and while I don't think you would actually break stuff by doing things differently, it's highly unintuitive.

The only reason I can think of to put the branch name in the package name is so that you can add two different branches as dependencies at the same time, which I dearly hope is not necessary, as it could easily lead to a mess of old unmaintained branches sticking around because other projects depend on them.

Yeah, that's what I want to do. I forgot that difference between name and version tag

EDIT: I've tried setting an environment variable, but I get an error:

code:

'$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)-$(SourceBranchName)' is not a valid version string. (Parameter 'value')

Boz0r fucked around with this message at 10:17 on Jun 8, 2020

# ¿ Jun 8, 2020 09:41

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Continuous Integration/build engineering/devops thread