Public Linking PR Docs For #906
Conversation
|
/azp run imodel-native |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
|
||
| ## Expected Behavior | ||
| ### For a native and core change | ||
| 1. The native pipeline should begin and build to completion. The `Build itwinjs-core` Stage should not be skipped |
There was a problem hiding this comment.
Is the Build itwinjs-core stage skipped ever? 'should not be skipped' sort of implies to me that it might be in some cases?
There was a problem hiding this comment.
Technically they can be skipped, but it depends on specifics. There's a long list of conditions for that stage. It generally shouldn't, but i'm not sure if its 100%
| ### For a native and core change | ||
| 1. The native pipeline should begin and build to completion. The `Build itwinjs-core` Stage should not be skipped | ||
| 1. There is currently no solution for stopping the iTwinJs Pipeline, so that will run as if nothing is linked, and will most likely fail. | ||
| 1. Upon completion of the native pipeline, the status check on your core PR should be updated |
There was a problem hiding this comment.
Does the status check have a name?
There was a problem hiding this comment.
It does, but I think it might not be necessary anymore. This was more important before addons were automatically integrated. I think this can be removed now
There was a problem hiding this comment.
when a new addon is pushed to the branch it deletes that check anyway, so its no longer visible
build/linking-prs.md
Outdated
| - `imodel-native: https://github.com/iTwin/imodel-native/pull/PULL-NUM` | ||
| 1. If you already created the PRs just add this links to your PR description and then in the imodel-native PR comment `/azp run imodel-native` to retrigger the pipelines. | ||
| 1. Wait until your pipeline succeeds and *both* PRs are approved. | ||
| 1. One both PRs are approved merge the imodel-native PR. This will create a new release with your change and automatically add the new release of the addon to your itwinjs-core PR. (This may take a few hours to build and publish your changes) |
There was a problem hiding this comment.
I guess since these are 'public' docs that means the intended audience will not have access to the pipelines that are running right? Theres sort of a hidden extra step here that you should be watching over the pipeline that is building your code to create a new release, right? Does that mean bentley developers will be expected to perform that step for them?
There was a problem hiding this comment.
Yeah, tbh devs don't do that now anyway, but people should be watching for the addons to be created. This is party why i don't know if its worth even having a document like this. Should we even allow someone outside to attempt a change like this. Is it even realistic to expect someone to be able to make a change across repos without the ability to build native (and maybe core, because certain tests i believe require permissions)
There was a problem hiding this comment.
Its a good point, does feel like we are skipping the part where devs should be able to build native locally and jumping straight to letting them know how to make a PR. Maybe simpler PRs would be possible , but can they even see build errors in our private pipeline runs to iterate on their code? ( I dont think so?)
There was a problem hiding this comment.
maybe within the gh screen, but not sure tbh. I know GH shows some kind of error message from azure, but I never really look closely to see how useful it is
Co-authored-by: Nick Tessier <[email protected]>
Co-authored-by: Nick Tessier <[email protected]>
Public Docs for anyone who might use PR validation. Also greatly slimmed down from current docs, and hopefully easier to read.
Don't know if location is great. Maybe it should be in a Docs dir or something?