Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: next steps in dev-stack? #718

Open
1letter opened this issue Apr 2, 2021 · 1 comment
Open

Question: next steps in dev-stack? #718

1letter opened this issue Apr 2, 2021 · 1 comment

Comments

@1letter
Copy link
Contributor

1letter commented Apr 2, 2021

I have working on SVG-Flag-Files Support in the Language Selector.

4 Packages are involved:

  • plone.staticresources
  • plone.i18n
  • plone.app.i18n
  • plone.app.multilingual

What i have done:

  • branching and working on every package
  • locally all is fine
  • push my branches to remote

My Question: what are the next steps in order not to lose the overview of things? Should i do PR in every repro (probably yes)? But everything is related, what happen if one PR is accepted but another not? Is here in the coredev anything needed? Should i update the checkouts.cfg?

@mauritsvanrees
Copy link
Member

What I would usually do:

  1. Create one overall issue in Products.CMFPlone that you can link to and generally keep track of what still needs to happen.
  2. Create PRs for all packages. In each PR link to the main issue and make it clear that this PR belongs to other PRs and they need to be merged together.
  3. Login on Jenkins, go to the relevant jobs and in the dropdown click on 'Build with parameters'. In the form, copy the URLs of all PRs.

Alternative to step 3 is to edit the sources.cfg of the coredev buildout to point to your branches instead of master (or main). Make sure they are in the checkouts too. Create a branch of coredev and make a PR of that. This makes it a bit easier for others: they can just checkout your coredev branch, run buildout, and test it. When all is approved, the coredev PR should not be merged, but closed, and the other PRs merged instead.

When PRs that belong together get merged, Jenkins probably already starts after the merge of the first, which may mean Jenkins gets failures, but that can't be avoided. Once all are merged, Jenkins should be green again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants