3

Jenkins has been around for longer so it has a larger installed base. It doesn't matter if AWS has something that is cheaper and better. Many places don't want to put the time and energy into upgrading Jenkins. Migrating to a new CI pipeline is even "scarier" -- regardless of whether it would be a wise strategic decision. Jenkins 1.x made this far worse ...


3

It may be helpful to look at the different AWS developer services as you are trying to achieve your goal in the wrong services: Running the specific dotnet testing and publish steps are not done in CodeDeploy. Rather, they would be done in AWS CodeBuild, in the AWS Pipeline, or directly on your Jenkins Server. AWS CodeDeploy is for taking your build ...


2

Checkout this solution with codepipeline. https://aws.amazon.com/blogs/big-data/implement-continuous-integration-and-delivery-of-serverless-aws-glue-etl-applications-using-aws-developer-tools/


2

In the CodeBuild "Artifacts" configuration, there is an "Add Artifact" button. You need to click that and reference your secondary artifact to get it to upload to S3 as well.


1

A bit too long for a comment, so converting to an answer: That's super broad and highly depends on your final needs IMHO, if you're full AWS and ok with being vendor locked down, then code commit/code build/code pipeline is great as it's nicely integrated now. If you have needs outside pure AWS services, that may get harder, for exemple if you plan on ...


1

In my opinion there should be a staging branch , which holds the production candidate code.And instead of a Test env , have a staging env which will be complete replica of Prod env. In the Staging env the QA can perform their testing and other checks. Dev env = only for developer. Stage env = Replica of Prod and holds production candidate build/code , ...


1

I would suggest adding a job that checks changes in the latest commit and build only that service where some files have been changed.


1

There should be a log group available in CloudWatch that you can refer to for information on the error. Also, there is an Execution History tab available on the left hand side that will let you see any errors that are not logged to CloudWatch. From the sounds of it there may be a problem with the source repo you have selected. It should only take a few ...


1

If you are unit testing, you should be mocking external dependencies like Spark and AWS Glue. Look into Python mocking frameworks like unittest.mock, monkeypatch and pytest-mock. Your unit tests should just test your code and how it interacts with Spark and AWS Glue. Your unit tests should not test Spark and AWS Glue functionality. Do that in your ...


Only top voted, non community-wiki answers of a minimum length are eligible