Hi Wilfred
Thanks for the proposals. I am
+1 to
e2e-tests:
needs: build
runs-on: ubuntu-latest
I feel a little concerned about the second proposal. Are we seeing any
issues with today's pipeline that inspire you with this proposal?
On Tue, Aug 23, 2022 at 8:02 AM Craig Condit <ccon...@apache.org> wrote:
> I think I would be +1 on the e2e-after-build proposal, but I’m a strong -1
> on pre-commit enforcement. Due to the interdependencies between our
> different modules, there have been (and likely will be again) scenarios
> where we need to push multiple changes to get a build back into a “healthy
> state” after some refactoring. This gets very complicated if we can’t
> commit to a branch without a passing build. Conversely, we have yet (to my
> knowledge) encountered a scenario where the build was broken for an
> extended (or even short?) time in the master branch - we already get
> notifications if a build fails after commit and in my experience these have
> been dealt with very swiftly.
>
> Craig
>
>
> > On Aug 22, 2022, at 11:42 PM, Wilfred Spiegelenburg <wilfr...@apache.org>
> wrote:
> >
> > While looking at the way we run our build jobs at the moment we start
> > the e2etest job in parallel with the build job of the k8shim. These
> > tests run for 25-30 minutes. They all get started even if the
> > compilation fails or we do not pass the unit tests.
> > Should we not wait for a successful build job before we start the e2e
> > tests? If the build job does not succeed we should never commit the
> > change anyway.
> >
> > Proposal is to change the flow and commit requirements.
> >
> > First proposal is to update the k8shim workflow [1] with the following
> > change that requires a successful build job before starting the
> > e2e-tests:
> > -------
> > e2e-tests:
> > needs: build
> > runs-on: ubuntu-latest
> > -------
> > The build which includes a number of checks and the unit tests is
> > quick. We really do not want or need to proceed with running the e2e
> > tests if the build job has failed. The job build will run and on
> > successful completion the e2e-tests job will run automatically.
> >
> > Second proposal is that we also enforce a passed build job before
> > commit. Turning on branch protection and requiring the build job to
> > pass before a commit is manageable from the asf.yaml file we already
> > maintain. This makes sure that we have at least the base tests
> > passing. Not all e2e tests might pass but confidence is at least
> > higher.
> > -----
> > github:
> > protected_branches:
> > master:
> > required_status_checks:
> > strict: false
> > contexts:
> > - build
> > required_pull_request_reviews:
> > dismiss_stale_reviews: false
> > required_approving_review_count: 1
> > required_linear_history: true
> > required_signatures: false
> >
> > # The following branch protections only ensure that force pushes are not
> allowed
> > branch-1.1: {}
> > branch-1.0: {}
> > branch-0.12: {}
> > branch-0.11: {}
> > branch-0.10: {}
> > branch-0.9: {}
> > branch-0.8: {}
> > -----
> >
> > This branch protection we can add to all code repos: core, k8shim,
> > scheduler-interface and web to stay consistent.
> >
> > Comments are welcome. If there are no comments in the next week I'll
> > log a jira and start the work to update the workflow and branch
> > protection early September.
> >
> > Wilfred
> >
> > [1]
> https://github.com/apache/yunikorn-k8shim/blob/master/.github/workflows/main.yml
> > [2]
> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-Branchprotection
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org
> > For additional commands, e-mail: dev-h...@yunikorn.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org
> For additional commands, e-mail: dev-h...@yunikorn.apache.org
>
>
