7 Commits
Author SHA1 Message Date
ohemorangeandGitHub 1d2540629f Use a different timeout for nightly vs daytime (release and extended) builds (#9330) 2022-06-22 18:06:53 -07:00
Brad WarrenandGitHub 4e9d3afcc4 Docker build improvements (#8218)
Fixes https://github.com/certbot/certbot/issues/8208.
Fixes https://github.com/certbot/certbot/issues/8198.

In addition to those two linked issues, this PR:

* Splits both the build and deploy steps based on architecture for performance. The Docker builds should no longer be the bottleneck in any stage of the pipeline.
* Skips building Docker images for ARM on `test-` branches like [we do for snaps](https://github.com/certbot/certbot/blob/e8a232297d6faedb3b0bffc197a2e98c2e59edcb/.azure-pipelines/templates/jobs/packaging-jobs.yml#L67-L71). I initially didn't want to do this, but the ARM builds take ~18 minutes which is significantly longer than any other job currently running on our `test-` branches.

You can see tests running on my fork at:

* [Release pipeline](https://dev.azure.com/bmw0523/bmw/_build/results?buildId=387&view=results)
* [Test pipeline](https://dev.azure.com/bmw0523/bmw/_build/results?buildId=388&view=results)
* [Nightly pipeline](https://dev.azure.com/bmw0523/bmw/_build/results?buildId=390&view=results)

* update script intro

* update readme

* ParseRequestedArch

* build all arch in Azure

* Build docker images during testing/packaging.

* require global variable?

* Error if TAG_BASE is empty.

* prepare build job

* change variable syntax

* Update deploy stage.

* remove old dockerTag param

* add displayName

* fix docker images command

* split docker_build by arch

* Allow deploying a subset of architectures.

* deploy in parallel

* Skip ARM builds on test- branches.

* fix spacing
2020-08-18 10:48:01 -07:00
Brad WarrenandGitHub b3dd2c09ba Remove release branch notification cruft. (#8196) 2020-08-11 12:50:54 -07:00
Brad WarrenandGitHub 072c070c0c Do not run tests on pushes to *.x for performance. (#8185) 2020-07-31 12:47:47 -07:00
Adrien FerrandandGitHub 8a3a8c7097 Migrate the CI pipeline from Travis to Azure Pipeline (#8098)
Fixes #8071 and fixes https://github.com/certbot/certbot/issues/8110.

This PR migrates every job from Travis in Azure Pipeline.

This PR essentially converts the Travis jobs into Azure Pipeline with a complete iso-fonctionality (or I made a mistake). The jobs are added in the relevant existing pipelines (`main`, `nightly`, `advanced-test`, `release`). A global refactoring thanks to the templating system is done to reduce greatly the verbosity of the pipeline descriptions.

A specific feature (not present in Travis) is added: the stage `On_Failure`. Using directly the Mattermost API, it allows to notify pipeline failure in a Mattermost channel with a link to the failed pipelines without the need to authenticate to Microsoft.

See https://github.com/certbot/certbot/pull/8098#issuecomment-649873641 for the post merge actions to do at the end of this work.
2020-07-02 15:01:21 -07:00
Brad WarrenandGitHub 50ea608553 Don't run advanced tests on PRs. (#7820)
When I wrote https://github.com/certbot/certbot/pull/7813, I didn't understand the default behavior for pull requests if you don't specify `pr` in the yaml file. According to https://docs.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#pr-triggers:

> If no pr triggers appear in your YAML file, pull request builds are automatically enabled for all branches...

This is not the behavior we want. This PR fixes the problem by disabling builds on PRs.

You should be able to see this working because the advanced tests should not run on this PR but they did run on https://github.com/certbot/certbot/pull/7811.
2020-02-27 15:07:33 -08:00
Brad WarrenandGitHub f4c0a9fd63 Split advanced pipeline (#7813)
I want to do what I did in https://github.com/certbot/certbot/pull/7733 to our Azure Pipelines setup, but unfortunately this isn't currently possible. The only filters available for service hooks for the "build completed" trigger are the pipeline and build status. See 
![Screen Shot 2020-02-26 at 3 04 56 PM](https://user-images.githubusercontent.com/6504915/75396464-64ad0780-58a9-11ea-97a1-3454a9754675.png)

To accomplish this, I propose splitting the "advanced" pipeline into two cases. One is for builds on protected branches where we want to be notified if they fail while the other is just used to manually run tests on certain branches.
2020-02-27 10:43:41 -08:00