feat(pipelines): ✨ Config allowed pipeline branches #500
Conversation
…ow at the config level
|
I've just realised that I can extend Plus, it's a little nicer this way because extending |
| if (pipelineObjects && projectObj) { | ||
| pipelineObjects.forEach((element) => { | ||
| element.project_name = projectObj.name; | ||
| }); | ||
| } | ||
| return pipelineObjects || undefined; | ||
|
|
||
| const relevantPipelineObjects = refList |
There was a problem hiding this comment.
Doing this can reduce the number of pipelines you get:
Example
Having this annotation:
gitlab.com/pipeline-refs: 'main,develop'
if in your last 50 pipelines, 49 are in branches different from main and develop you will get only one pipeline in your card. Then you can make a request for each branch ex. /projects/2416/pipelines?ref=${branch} (with this approach you get more pipelines than before) or better you can use graphql
There was a problem hiding this comment.
Thanks @antoniomuso, good catch haven't forgotten about this - just swamped with other work. Hoping to pick this back up in early aug :)
|
Made some changes, this was the best I could come up with while maintaining the wildcard functionality I added. |
| let page = 1; | ||
| let response; | ||
| do { | ||
| response = await this.callApi<PipelineSchema[]>( |
There was a problem hiding this comment.
You cannot crawl all pipelines because it can be very inefficient. I suggest using branches API, to get all eligible branches and then query the pipelines API with the right branches.
There was a problem hiding this comment.
'Branches' API has the qs parameter search that is very useful to implement the wildcard.
There was a problem hiding this comment.
Can do. How do you recommend configuring the plugin so that you can test the backend against a real GitLab instance locally? I've been running yarn start which only tests with the mock response with mock queries.
There was a problem hiding this comment.
Yes, it is hard to test with a real GitLab instance; I have to work on it to increase DevEx. I usually test it by integrating it into a pre-configured backstage environment configured with gitlab.com and I usually link the library using yarn.
|
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
🚨 Proposed changes
Adds the option for an entity to configure a a whitelist of "refs" which will be shown in the Gitlab Pipelines table. If not configured, all refs/branches will show by default.
EG:
gitlab.com/pipeline-refs: 'main,develop,feature/*'Feedback from stakeholders I've worked with has been that the table is too cluttered, and that they just want to see an overview of the pipelines on the most important branches. (Probably because they don't want to see "failed, failed failed" for pipelines which run on MRs and testing branches). Obviously you can use the table filter to drill down but:
An alternative solution to this would be to have a
[x] Show Default Branchcheckbox under the card title which is defaulted to checked, or maybe[x] Show Relevant Brancheswhich would show thedefault branch + ^dev(elop(ment)?)?"$. I'm happy to contribute something like that instead if you'd prefer.⚙️ Types of changes
What types of changes does your code introduce? Put an
xin the boxes that apply